idnits 2.17.1 draft-ietf-dmarc-arc-protocol-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 24, 2018) is 2133 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 1483 -- Looks like a reference, but probably isn't: '1' on line 1481 == Missing Reference: 'I-D.ARC' is mentioned on line 1057, but not defined -- Looks like a reference, but probably isn't: '3' on line 1485 -- Looks like a reference, but probably isn't: '4' on line 1487 -- Looks like a reference, but probably isn't: '5' on line 1532 -- Looks like a reference, but probably isn't: '6' on line 1556 -- Looks like a reference, but probably isn't: '7' on line 1557 -- Looks like a reference, but probably isn't: '8' on line 1558 -- Looks like a reference, but probably isn't: '9' on line 1561 == Unused Reference: 'RFC7601' is defined on line 1405, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7601 (Obsoleted by RFC 8601) == Outdated reference: A later version (-23) exists of draft-ietf-dmarc-arc-protocol-05 == Outdated reference: A later version (-23) exists of draft-ietf-dmarc-arc-protocol-10 -- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in 'ARC-DRAFT-10', was also mentioned in 'ARC-DRAFT-05'. == Outdated reference: A later version (-23) exists of draft-ietf-dmarc-arc-protocol-13 -- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in 'ARC-DRAFT-13', was also mentioned in 'ARC-DRAFT-10'. == Outdated reference: A later version (-23) exists of draft-ietf-dmarc-arc-protocol-14 -- Duplicate reference: draft-ietf-dmarc-arc-protocol, mentioned in 'ARC-DRAFT-14', was also mentioned in 'ARC-DRAFT-13'. == Outdated reference: A later version (-03) exists of draft-ietf-dmarc-arc-multi-01 == Outdated reference: A later version (-09) exists of draft-ietf-dmarc-arc-usage-05 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC Working Group K. Andersen 3 Internet-Draft LinkedIn 4 Intended status: Experimental B. Long, Ed. 5 Expires: December 26, 2018 Google 6 S. Blank, Ed. 7 Valimail 8 M. Kucherawy, Ed. 9 TDP 10 T. Draegon, Ed. 11 dmarcian 12 June 24, 2018 14 Authenticated Received Chain (ARC) Protocol 15 draft-ietf-dmarc-arc-protocol-15 17 Abstract 19 The Authenticated Received Chain (ARC) protocol allows Internet Mail 20 Handlers to attach assertions of message authentication state to 21 individual messages. As messages traverse ARC-enabled Internet Mail 22 Handlers, additional ARC assertions can be attached to messages to 23 form ordered sets of ARC assertions that represent authentication 24 state along each step of message handling paths. 26 ARC-enabled Internet Mail Handlers can process sets of ARC assertions 27 to inform message disposition decisions, to identify Internet Mail 28 Handlers that might break existing authentication mechanisms, and to 29 convey original authentication state across trust boundaries. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 26, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Note to Reviewers in the DMARC WG . . . . . . . . . . . . 4 67 2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 5 71 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5 72 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 73 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7 75 3.3. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.4. Validator . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 7 78 3.6. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 79 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 80 4.1. ARC Headers . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 8 82 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 8 83 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 9 84 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 11 86 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 11 87 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 11 88 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 12 89 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 12 90 5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 13 91 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 13 92 5.1.3. Only One Authenticated Received Chain Per Message . . 14 93 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 14 94 5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 14 95 5.1.6. Signing vs Sealing . . . . . . . . . . . . . . . . . 14 97 5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 14 98 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 16 99 5.2.2. Responding to ARC Validation Failures During the SMTP 100 Transaction . . . . . . . . . . . . . . . . . . . . . 16 101 5.3. Result of Validation . . . . . . . . . . . . . . . . . . 16 102 6. Communication of Validation Results . . . . . . . . . . . . . 17 103 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 7.1. Communicate Authentication Results Across Trust 105 Boundaries . . . . . . . . . . . . . . . . . . . . . . . 17 106 7.1.1. Message Scanning Services . . . . . . . . . . . . . . 18 107 7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 18 108 7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 18 109 7.2. Inform Message Disposition Decisions . . . . . . . . . . 19 110 7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 19 111 7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 19 112 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 114 9.1. Increased Header Size . . . . . . . . . . . . . . . . . . 21 115 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21 116 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21 117 9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 22 118 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22 119 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 120 10.1. Email Authentication Results Names Registry Update . . . 22 121 10.2. Email Authentication Methods Registry Update . . . . . . 22 122 10.3. Definitions of the ARC header fields . . . . . . . . . . 23 123 11. Experimental Considerations . . . . . . . . . . . . . . . . . 23 124 11.1. Success Consideration . . . . . . . . . . . . . . . . . 23 125 11.2. Failure Considerations . . . . . . . . . . . . . . . . . 24 126 11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24 127 11.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24 128 11.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24 129 11.3.3. What Trace Information is Valuable . . . . . . . . . 24 130 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 131 12.1. GMail test reflector and incoming validation . . . . . . 26 132 12.2. AOL test reflector and internal tagging . . . . . . . . 26 133 12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 26 134 12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27 135 12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 27 136 12.6. Copernica/MailerQ web-based validation . . . . . . . . . 27 137 12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28 138 12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 28 139 12.9. PERL Mail::Milter::Authentication module . . . . . . . . 28 140 12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29 141 12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 29 142 12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 29 143 12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 29 144 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 145 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 146 13.2. Informative References . . . . . . . . . . . . . . . . . 31 147 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 148 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 32 149 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 33 150 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 33 151 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 33 152 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 33 153 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 34 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 156 1. Introduction 158 The utility of widely deployed email authentication technologies such 159 as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified 160 Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail 161 by intermediate handlers. This impact is thoroughly documented in 162 the defining documents for SPF and DKIM and further discussed in 163 [RFC6377] and [RFC7960]. 165 The utility of technologies that build upon SPF and DKIM (such as 166 DMARC [RFC7489]) is similarly impacted by intermediate handlers. The 167 disruption of authentication mechanisms for legitimate messages by 168 intermediate handlers can impact all aspects of Internet Mail - 169 message authors, message recipients, and even the intermediary 170 handler itself. 172 Authenticated Received Chain (ARC) creates a mechanism for individual 173 Internet Mail Handlers to add their authentication processing results 174 to a message's ordered set of processing results. ARC encapsulates 175 processing results in a DKIM signature derivative to grant other 176 handlers the ability to verify the authenticity of each individual 177 processing results as well as the aggregate set and sequence of 178 results. 180 Ordered sets of processing results can be used by ARC-enabled 181 Internet Mail Handlers to inform message handling disposition, to 182 identify where alteration of message content might have occurred, and 183 to provide additional trace information for use in understanding 184 message handling paths. 186 1.1. Note to Reviewers in the DMARC WG 188 [[ Note: This section is editorial to the WG. Will be removed for 189 final version. ]] 190 This version of the draft has been extensively reorganized for 191 readability. No changes to the wire protocol or specification are 192 intended from [ARC-DRAFT-14]. 194 2. General Concepts 196 ARC is loosely based on concepts from evidence collection. Evidence 197 is usually collected, labeled, stored, and transported in specific 198 ways to preserve the state of evidence and to document all processing 199 steps. 201 2.1. Evidence 203 In ARC's situation, the "evidence" is a message's authentication 204 state at any point along the delivery path between origination and 205 final delivery. Authentication state can change when intermediate 206 handlers modify message content, route messages through unforeseen 207 paths, or change envelope information. 209 2.2. Custody 211 "Custody" refers to when an ARC-enabled Internet Mail Handler 212 processes a message. When a handler takes custody of a message, the 213 handler becomes a Custodian and attaches their own evidence 214 (authentication state upon receipt) to the message. Evidence is 215 added in such a way so that future handlers can verify the 216 authenticity of both evidence and custody. 218 2.3. Chain of Custody 220 The "chain of custody" of ARC is the entire set of evidence and 221 custody that travels with a message. 223 2.4. Validation of Chain of Custody 225 Any ARC-enabled Internet Mail Handler can validate the entire set of 226 evidence and custody to yield a valid Chain of Custody. If the 227 evidence-supplying Custodians can be trusted, then the validated 228 Chain of Custody describes the (possibly changing) authentication 229 state as the message traveled through various Custodians. 231 Even though a message's authentication state might have changed, the 232 validated chain of custody can be used to determine if the changes 233 (and the Custodians responsible for the changes) can be tolerated. 235 3. Terminology and Definitions 237 This section defines terms used in the rest of the document. 239 Readers should to be familiar with the contents, core concepts, and 240 definitions found in [RFC5598]. The potential roles of 241 intermediaries in the delivery of email is directly relevant. 243 Language, syntax (including some ABNF constructs), and concepts are 244 imported from DKIM [RFC6376]. Specific references to DKIM are made 245 throughout this document. The following terms are imported from 246 [RFC5598]: 248 o ADministrative Management Domain (ADMD), Section 2.3 250 o Message Transfer Agents (MTA), Section 4.3.2 252 o Message Submission Agent (MSA), Section 4.3.1 254 o Message Delivery Agent (MDA), Section 4.3.3 256 Internet Mail Handlers process and deliver messages across the 257 Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists. 259 Syntax descriptions use Augmented BNF (ABNF) [RFC5234] and [RFC7405]. 261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 263 "OPTIONAL" in this document are to be interpreted as described in 264 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 265 capitals, as shown here. These words may also appear in this 266 document in lower case as plain English words, absent their normative 267 meanings. 269 3.1. ARC Set 271 Section Section 4.1 introduces three (3) ARC header fields. 272 Together, the 3 header fields compose a single "ARC Set". An ARC Set 273 provides the means for an Internet Mail Handler to attach 274 authentication state to a message in a manner that can be verified by 275 future handlers. A single message can contain multiple ARC Sets. 277 In General Concept terms, an ARC Set represents Evidence and Custody. 279 3.2. Authenticated Received Chain (ARC) 281 The complete sequence of ARC Sets attached to a message is called the 282 Authenticated Received Chain. An Authenticated Received Chain is a 283 recording of individual authentication states as a message traverses 284 through ARC-participating ADMDs. 286 The first attachment of an ARC Set to a message causes an 287 Authenticated Received Chain to be created. Additional attachments 288 of ARC Sets cause the Authenticated Received Chain to be extended. 290 In General Concept terms, an Authenticated Received Chain represents 291 Chain of Custody. 293 3.3. Sealer 295 A Sealer is an Internet Mail Handler that attaches a complete and 296 valid ARC Set to a message. 298 In General Concept terms, a Sealer adds Evidence and proof of Custody 299 to the Chain of Custody. 301 3.4. Validator 303 A Validator is an ARC-enabled Internet Mail Handler that evaluates an 304 Authenticated Received Chain for validity and content. The process 305 of evaluation of the individual ARC Sets that compose an 306 Authenticated Received Chain is described in Section Section 5.2. 308 In General Concept terms, a Validator inspects the Chain of Custody 309 to determine the content and validity of individual Evidence supplied 310 by Custodians. 312 3.5. Imported ABNF Tokens 314 The following ABNF tokens are imported: 316 o tag-list ([RFC6376] section 3.2) 318 o authres-payload ([I-D-7601bis] section 2.2) 320 o cfws ([RFC5322] section 3.2.2) 322 3.6. Common ABNF Tokens 324 The following ABNF tokens are used elsewhere in this document: 326 position = 1*2DIGIT ; 1 - 50 327 instance = [CFWS] %s"i" [CFWS] "=" [CFWS] position [CFWS] ";" 328 chain-status = ("none" / "fail" / "pass") 329 seal-cv-tag = %s"cv" [CFWS] "=" [CFWS] chain-status 331 4. Protocol Elements 333 4.1. ARC Headers 335 ARC introduces three new header fields. Syntax for new header fields 336 borrows heavily from existing specifications. This document only 337 describes where ARC-specific changes in syntax and semantics differ 338 from existing specifications. 340 4.1.1. ARC-Authentication-Results (AAR) 342 The ARC-Authentication-Results (AAR) header field records the message 343 authentication state as processed by an ARC-participating ADMD at 344 message arrival time. 346 In General Concept terms, the AAR header field is where Evidence is 347 recorded by a Custodian. 349 The AAR header field is similar in syntax and semantics to an 350 Authentication-Results field [I-D-7601bis], with two (2) differences: 352 o the name of the header field itself; 354 o the presence of the "instance tag". Additional information on the 355 "instance tag" can be found in Section Section 4.2.1. 357 The formal ABNF for the AAR header field is: 359 arc-info = instance [CFWS] ";" authres-payload 360 arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info 362 Because there is only one AAR allowed per ARC set, the AAR MUST 363 contain all authentication results from within the participating 364 ADMD, regardless of how many Authentication-Results headers are 365 attached to the message. 367 4.1.2. ARC-Message-Signature (AMS) 369 The ARC-Message-Signature (AMS) header field allows an ARC- 370 participating ADMD to convey some responsibility (custodianship) for 371 a message and possible message modifications to future ARC- 372 participating Custodians. 374 In General Concept terms, the AMS header field identifies a 375 Custodian. 377 The AMS header field is similar in syntax and semantics to a DKIM- 378 Signature field [RFC6376], with three (3) differences: 380 o the name of the header field itself; 382 o no version tag ("v") is defined for the AMS header. As required 383 for undefined tags (in [RFC6376]), if seen, a version tag MUST be 384 ignored; 386 o the presence of the "instance tag". Additional information on the 387 "instance tag" can be found in Section Section 4.2.1. The 388 instance tag replaces the DKIM "AUID" tag. 390 ARC places no requirements on the selectors and/or domains used for 391 the AMS header field signatures. 393 The formal ABNF for the AMS header field is: 395 arc-ams-info = instance [CFWS] ";" tag-list 396 arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info 398 To avoid unwanted invalidation of AMS signatures: 400 o AMS header fields are added by ARC-participating ADMDs as messages 401 exit the ADMD. AMS header fields should be attached so that any 402 modifications made by the ADMD are included in the signature of 403 the AMS header field. 405 o Authentication-Results header fields MUST NOT be included in AMS 406 signatures as they are likely to be deleted by downstream ADMDs 407 (per Section 5 of [I-D-7601bis]). 409 o ARC-related header fields (ARC-Authentication-Results, ARC- 410 Message-Signature, ARC-Seal) MUST NOT be included in the list of 411 header fields covered by the signature of the AMS header field. 413 To preserve the ability to verify the integrity of a message, the 414 signature of the AMS header field SHOULD include any DKIM-Signature 415 header fields already present in the message. 417 4.1.3. ARC-Seal (AS) 419 The ARC-Seal (AS) header field is the mechanism by which ARC- 420 participating ADMDs can verify the integrity of AAR header fields and 421 corresponding AMS header fields. 423 In General Concept terms, the AS header field is how Custodians bind 424 Evidence into a Chain of Custody so that Validators can inspect 425 individual Evidence and Custodians. 427 The AS header field is similar in syntax and semantics to DKIM- 428 Signatures [RFC6376], with the following differences: 430 o the presence of the "instance tag". Additional information on the 431 "instance tag" can be found in Section Section 4.2.1. 433 o the signature of the AS header field does not cover the body of 434 the message and therefore there is no 'bh' tag. The signature of 435 the AS header field only covers specific header fields as defined 436 in Section Section 5.1.1. 438 o no body canonicalization is performed as the AS signature does not 439 cover the body of a message. 441 o only "relaxed" header canonicalization ([RFC6376] section 3.4.2) 442 is used. 444 o the only supported tags are "i" (from Section Section 4.2.1 of 445 this document), and "a", "b", "d, "s", "t" from Section 3.5 of 446 [RFC6376]. Note especially that the DKIM "h" header is NOT 447 allowed and if found, MUST result in a cv status of "fail" (for 448 more information see Section 5.1.1; 450 o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF 451 definition) is used to communicate Chain Validation Status to 452 subsequent ADMDs. 454 ARC places no requirements on the selectors and/or domains used for 455 the AS header field signatures. 457 The formal ABNF for the AS header field is: 459 arc-as-info = instance [CFWS] ";" tag-list 460 arc-seal = "ARC-Seal:" [CFWS] arc-as-info 462 4.2. ARC Set 464 An "ARC Set" is a single collection of three ARC Headers (AAR, AMS, 465 and AS). ARC Headers of an ARC Set share the same "instance" value. 467 By adding all ARC Headers to a message, an ARC Sealer adds an ARC Set 468 to a message. A description of how Sealers add an ARC Set to a 469 message is found in Section Section 5.1. 471 4.2.1. Instance Tags 473 Instance tags describe which ARC Headers belong to an ARC Set. Each 474 ARC Header of an ARC Set shares the same instance tag value. 476 Instance tag values are integers that begin at 1 and are incremented 477 by each addition of an ARC Set. Through the incremental values of 478 instance tags, an ARC Validator can determine the order in which ARC 479 Sets were added to a message. 481 Instance tag values can range from 1-50 (inclusive). 483 Valid ARC Sets MUST have exactly one instance of each ARC Header 484 field (AAR, AMS, and AS) for a given instance value and signing 485 algorithm. 487 _INFORMATIONAL:_ Initial development of ARC is only being done with a 488 single allowed signing algorithm, but parallel work in the DCRUP 489 working group is expanding that. For handling multiple signing 490 algorithms, see [ARC-MULTI]. 492 4.3. Authenticated Received Chain 494 An Authenticated Received Chain is an ordered collection of ARC Sets. 495 As ARC Sets are enumerated sets of ARC Headers, an Authenticated 496 Received Chain represents the output of message authentication state 497 along the handling path of ARC-enabled processors. 499 Results of message authentication processing along each step of the 500 ARC-enabled handling path is present in an Authenticated Received 501 Chain in the form of AAR header fields. The ability to verify the 502 identity of message handlers and the integrity of message content is 503 provided by AMS header fields. AS header fields allow messages 504 handlers to validate the assertions, order and sequence of the 505 Authenticated Received Chain itself. 507 In General Concept terms, an Authenticated Received Chain represents 508 a message's Chain of Custody. Validators can consult a message's 509 Chain of Custody to gain insight regarding each Custodian of a 510 message and the Evidence collected by each Custodian. 512 4.4. Chain Validation Status 514 The state of the Authenticated Received Chain at a specific 515 processing step is called the "Chain Validation Status". Chain 516 Validation Status information is communicated in several ways: 518 o the AS header field in the "cv" tag, and 519 o as part of Authentication-Results and AAR headers. 521 Chain Validation Status has one of three possible values: 523 o none: There was no Authenticated Received Chain on the message 524 when it arrived for validation. Typically this occurs when a 525 message is received directly from a message's original Message 526 Transfer Agent (MTA) or Message Submission Agent (MSA), or from an 527 upstream Internet Mail Handler that is not participating in ARC 528 handling. 530 o fail: The message contains an Authenticated Received Chain whose 531 validation failed. 533 o pass: The message contains an Authenticated Received Chain whose 534 validation succeeded. 536 5. Protocol Actions 538 ARC-enabled Internet Mail Handlers generally act as both ARC Sealers 539 (when sending messages) and ARC Validators (when receiving messages). 541 5.1. Sealer Actions 543 To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC 544 header fields AAR, AMS, and AS) to a message. All ARC header fields 545 in an ARC Set share the same instance tag value. 547 To perform Sealing (aka to build and attach a new ARC Set), the 548 following actions must be taken by an ARC Sealer when presented with 549 a message: 551 1. All message modifications (including adding DKIM-Signatures) MUST 552 be performed before Sealing. 554 2. Calculate the instance value: if the message contains an 555 Authenticated Received Chain, the instance value is 1 more than 556 the highest instance number found in the Authenticated Received 557 Chain. If no Authenticated Received Chain exists, the instance 558 value is 1. 560 3. Using the calculated instance value, generate and attach to the 561 message in the following order: 563 4. An ARC-Authentication-Results header field as defined in 564 Section Section 4.1.1. 566 5. An ARC-Message-Signature header field as defined in 567 Section Section 4.1.2. 569 6. An ARC-Seal header field using the AS definition found in 570 Section Section 4.1.3, the method described in 571 Section Section 5.1.1, and the Chain Validation Status as 572 determined during ARC validation. 574 5.1.1. Header Fields To Include In ARC-Seal Signatures 576 The signature of an AS header field signs a specific canonicalized 577 form of the ARC Set header values. The ARC set header values are 578 supplied to the hash function in increasing instance order, starting 579 at 1, and include the ARC Set being added at the time of Sealing the 580 message. 582 Within an ARC Set, header fields are supplied to the hash function in 583 the following order: 585 1. ARC-Authentication-Results 587 2. ARC-Message-Signature 589 3. ARC-Seal 591 The ARC-Seal is generated in a manner similar to when DKIM-Signatures 592 are added to messages ([RFC6376], section 3.7). 594 Note that when an Authenticated Received Chain has failed validation, 595 the signing scope for the ARC-Seal is modified (see 596 Section Section 5.1.2). 598 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains 600 In the case of a failed Authenticated Received Chain, the header 601 fields included in the signature scope of the AS header field b= 602 value MUST only include the ARC Set headers created by the MTA which 603 detected the malformed chain, as if this newest ARC Set was the only 604 set present. 606 _INFORMATIONAL_: This approach is mandated to handle the case of a 607 malformed or otherwise invalid Authenticated Received Chain. There 608 is no way to generate a deterministic set of AS header fields 609 (Section 5.1.1) in most cases of invalid chains. 611 5.1.3. Only One Authenticated Received Chain Per Message 613 A message can have only one Authenticated Received Chain on it at a 614 time. Once broken, the chain cannot be continued, as the chain of 615 custody is no longer valid and responsibility for the message has 616 been lost. For further discussion of this topic and the designed 617 restriction which prevents chain continuation or re-establishment, 618 see [ARC-USAGE]. 620 5.1.4. Broad Ability to Seal 622 ARC is not solely intended for perimeter MTAs. Any mediator 623 ([RFC5598], section 5) that modifies a message may Seal its own 624 changes. For additional information, see Section Section 7.1. 626 5.1.5. Sealing is Always Safe 628 The utility of an Authenticated Received Chain is limited to very 629 specific cases. Authenticated Received Chains are designed to 630 provide additional information to an Internet Mail Handler when 631 evaluating messages for delivery in the context of authentication 632 failures. Specifically: 634 o Properly adding an ARC Set to a message does not damage or 635 invalidate an existing Authenticated Received Chain. 637 o Sealing an Authenticated Received Chain when a message has not 638 been modified does not negatively affect the chain. 640 o Validating a message exposes no new threat vectors (see 641 Section Section 9). 643 o An ADMD may choose to Seal all inbound messages whether or not a 644 message has been modified or will be retransmitted. 646 5.1.6. Signing vs Sealing 648 Signing is the process of affixing a digital signature to a message 649 as a header, such as when a DKIM-Signature (as in [RFC6376] section 650 2.1), or an AMS or AS is added. Sealing is when an ADMD affixes a 651 complete and valid ARC Set to a message creating or continuing an 652 Authenticated Received Chain. 654 5.2. Validator Actions 656 A validator performs the following steps, in sequence, to process an 657 Authenticated Received Chain. Canonicalization, hash functions, and 658 signature validation methods are imported from [RFC6376] section 5. 660 1. Collect all ARC Sets currently attached to the message. If there 661 are none, the Chain Validation Status is "none" and the algorithm 662 stops here. The maximum number of ARC Sets that can be attached 663 to a message is 50. If more than the maximum number exist the 664 Chain Validation Status is "fail" and the algorithm stops here. 665 In the following algorithm, the maximum ARC instance value is 666 referred to as "N". 668 2. If the Chain Validation Status of the highest instance value ARC 669 Set is "fail", then the Chain Validation status is "fail" and the 670 algorithm stops here. 672 3. Validate the structure of the Authenticated Received Chain. A 673 valid ARC has the following conditions: 675 1. Each ARC Set MUST contain exactly one each of the three ARC 676 header fields (AAR, AMS, and AS). 678 2. The instance values of the ARC Sets MUST form a continuous 679 sequence from 1..N with no gaps or repetition. 681 3. The "cv" value for all ARC-Seal header fields must be non- 682 failing. For instance values > 1, the value must be "pass". 683 For instance value = 1, the value must be "none". 685 * If any of these conditions are not met, the Chain Validation 686 Status is "fail" and the algorithm stops here. 688 4. Validate the AMS with the greatest instance value (most recent). 689 If validation fails, then the Chain Validation Status is "fail" 690 and the algorithm stops here. 692 5. _OPTIONAL:_ Determine the "oldest-pass" value from the ARC Set by 693 validating each prior AMS beginning with the N-1 and proceeding 694 in decreasing order to the AMS with the instance value of 1: 696 6. If an AMS fails to validate (for instance value "M"), then set 697 the oldest-pass value to the lowest AMS instance value which 698 passed (M+1) and go to the next step (there is no need to check 699 any other (older) AMS headers). This does not affect the 700 validity of the Authenticated Received Chain. 702 7. If all AMS headers verify, set the oldest-pass value to zero (0). 704 8. Validate each AS beginning with the greatest instance value and 705 proceeding in decreasing order to the AS with the instance value 706 of 1. If any AS fails to validate, the Chain Validation Status 707 is "fail" and the algorithm stops here. 709 9. If the algorithm reaches this step, then the Chain Validation 710 Status is "pass", and the algorithm is complete. 712 The end result of this Validation algorithm is added into the 713 Authentication-Results header for the ADMD. 715 As with a failing DKIM signature ([RFC6376] section 6.3), a message 716 with a failing Authenticated Received Chain MUST be treated the same 717 as a message with no Authenticated Received Chain. 719 _INFORMATIONAL_: Recipients of an invalid or failing Authenticated 720 Received Chain can use that information as part of a wider handling 721 context. ARC adoption cannot be assumed by intermediaries; many 722 intermediaries will continue to modify messages without adding ARC 723 Seals. 725 5.2.1. All Failures Are Permanent 727 Authenticated Received Chains represent the traversal of messages 728 through one or more intermediaries. All errors, including DNS 729 failures, become unrecoverable and are considered permanent. 731 Any error Validating an Authenticated Received Chain results in a 732 failed Chain Validation Status. For further discussion of this topic 733 and the design restriction which prevents chain continuation or re- 734 establishment, see [ARC-USAGE]. 736 5.2.2. Responding to ARC Validation Failures During the SMTP 737 Transaction 739 If an ARC Validator determines that the Authenticated Received Chain 740 has failed, the Validator MAY signal the breakage through the 741 extended SMTP response code 5.7.7 [RFC3463] "message integrity 742 failure" [ENHANCED-STATUS] and corresponding SMTP response code. 744 5.3. Result of Validation 746 An Authenticated Received Chain with a Chain Validation Status of 747 "pass" allows Internet Mail Handlers to ascertain: 749 o all ARC-participating ADMDs that claim responsibility for handling 750 (and possibly modifying) the message in transit; 752 o the authentication state of the message as perceived by each ADMD 753 (from Authentication-Results header fields). 755 Given this information, handlers can inform local policy decisions 756 regarding disposition of messages that experience authentication 757 failure due to intermediate processing. 759 6. Communication of Validation Results 761 Chain Validation Status (described in Section Section 4.4) is 762 communicated via Authentication-Results (and AAR) headers using the 763 auth method "arc". This auth method is described in 764 Section Section 10.1. 766 If necessary data is available, the ptypes and properties defined in 767 Section Section 10.2 SHOULD be recorded in an Authentication-Results 768 header field: 770 o smtp.client-ip - The connecting client IP address from which the 771 message is received. 773 o header.oldest-pass - The instance number of the oldest AMS that 774 still validates, or 0 if all pass. 776 Upon Sealing of a message, this Authentication-Results information 777 along with all other Authentications-Results added by the ADMD will 778 be recorded into the AAR as defined in section Section 4.1.1. 780 In General Concept terms, the information recorded in the ARC- 781 Authentication-Results header field is the Evidence that gets 782 attached to a message. 784 7. Use Cases 786 This section explores several messaging handling use cases that are 787 addressed by ARC. 789 7.1. Communicate Authentication Results Across Trust Boundaries 791 When an intermediary ADMD adds an ARC Set to a message's 792 Authenticated Received Chain (or creates the initial ARC Set), the 793 ADMD communicates authentication state to the next ADMD in the 794 message handling path. 796 If ARC-enabled ADMDs are trusted, Authenticated Received Chains can 797 be used to bridge administrative boundaries. 799 7.1.1. Message Scanning Services 801 Message services are available to perform anti-spam, anti-malware, 802 and anti-phishing scanning. Such services typically remove malicious 803 content, replace HTTP links in messages with sanitized links, and/or 804 attach footers to messages advertising the abilities of the message 805 scanning service. These modifications almost always break signature- 806 based authentication (such as DKIM). 808 Scanning services typically require clients to point MX records of an 809 Internet domain to the scanning service. Messages destined for the 810 Internet domain are initially delivered to the scanning service. 811 Once scanning is performed, messages are then routed to the client's 812 own mail handling infrastructure. Re-routing messages in this way 813 almost always breaks path-based authentication (such as SPF). 815 Message scanning services can attach Authenticated Received Chains to 816 messages to communicate authentication results into client ADMDs. 817 Clients can then benefit from the message scanning service while 818 processing messages as if the client's infrastructure were the 819 original destination of the Internet domain's MX record. 821 7.1.2. Multi-tier MTA Processing 823 Large message processing infrastructure is often divided into several 824 processing tiers that can break authentication information between 825 tiers. For example, a large site may maintain a cluster of MTAs 826 dedicated to connection handling and enforcement of IP-based 827 reputation filtering. A secondary cluster of MTAs may be dedicated 828 and optimized for content-based processing of messages. 830 Authenticated Received Chains can be used to communicated 831 authentication state between processing tiers. 833 7.1.3. Mailing Lists 835 Mailing lists resend posted messages to subscribers. A full 836 description of authentication-related mailing list issues can be 837 found in [RFC7960] Section 3.2.3. 839 Mailing list services can implement ARC to convey the original 840 authentication state of posted messages sent to the list's subscriber 841 base. The ADMDs of the mailing list subscribers can then use the 842 Authenticated Received Chain to determine the authentication state of 843 the original message before mailing list handling. 845 7.2. Inform Message Disposition Decisions 847 ARC functionality allows Internet Mail Handlers to reliably identify 848 intermediary ADMDs and for ADMDs to expose authentication state that 849 can survive additional intermediary handling. 851 Intermediaries often break authentication through content 852 modification, interfere with path-based authentication (such as SPF), 853 and strip authentication results (if an MTA removes Authentication- 854 Results headers). 856 Authenticated Received Chains allow ARC Validators to: 858 1. identify ARC-enabled ADMDs that break authentication while 859 processing messages; 861 2. gain extended visibility into the authentication-preserving 862 abilities of ADMDs that relay messages into ARC-enabled ADMDs. 864 Through the collection of ARC-related data, an ADMD can identify 865 handling paths that have broken authentication. 867 An Authenticated Received Chain allows an Internet Mail Handler to 868 potentially base decisions of message disposition on authentication 869 state provided by different ADMDs. 871 7.2.1. DMARC Local Policy Overrides 873 DMARC introduces a policy model where Domain Owners can request email 874 receivers to reject or quarantine messages that fail DMARC alignment. 875 Interoperability issues between DMARC and indirect email flows are 876 documented in [RFC7960]. 878 Authenticated Received Chains allow DMARC processors to consider 879 authentication states provided by other ADMDs. As a matter of local 880 policy, a DMARC processor may choose to accept the authentication 881 state provided by an Authenticated Received Chain when determining if 882 a message is DMARC compliant. 884 When an Authenticated Received Chain is used to determine message 885 disposition, the DMARC processor can communicate this local policy 886 decision to Domain Owners as described in Section Section 7.2.2. 888 7.2.2. DMARC Reporting 890 DMARC-enabled receivers indicate when ARC Validation influences 891 DMARC-related local policy decisions. DMARC reporting of ARC- 892 influenced decisions is accomplished by adding a local_policy comment 893 containing a list of data discovered during ARC Validation, which at 894 a minimum includes: 896 o the Chain Validation Status, 898 o the domain and selector for each AS, 900 o the originating IP address from the first ARC Set: 902 EXAMPLE: 904 905 none 906 fail 907 fail 908 909 local_policy 910 arc=pass ams[2].d=d2.example ams[2].s=s1 911 as[2].d=d2.example as[2].s=s2 as[1].d=d1.example 912 as[1].s=s3 client-ip[1]=10.10.10.13 913 914 916 In the above example DMARC XML reporting fragment, data relating to 917 specific validated ARC Sets are enumerated using array syntax (eg, 918 "ams[2]" means AMS header field with instance value of 2). d2.example 919 is the Sealing domain for ARC Set #2 (i=2) and d1.example is the 920 Sealing domain for ARC Set #1 (i=1). 922 Depending on the reporting practices of intermediate message 923 handlers, Domain Owners may receive multiple DMARC reports for a 924 single message. DMARC report processors should be aware of this 925 behaviour and make the necessary accommodations. 927 8. Privacy Considerations 929 The Authenticated Received Chain provides a verifiable record of the 930 handlers for a message. This record may include Personally 931 Identifiable Information such as IP address and domain names. Such 932 information is also including in existing header fields such as the 933 "Received" header field. 935 9. Security Considerations 937 The Security Considerations of [RFC6376] and [I-D-7601bis] apply 938 directly to this specification. 940 As with other domain authentication technologies (such as SPF, DKIM, 941 and DMARC), ARC makes no claims about the semantic content of 942 messages. 944 9.1. Increased Header Size 946 Inclusion of Authenticated Received Chains into messages may cause 947 issues for older or constrained MTAs due to increased total header 948 size. 950 9.2. DNS Operations 952 The validation of an Authenticated Received Chain composed of N ARC 953 Sets can require up to 2*N DNS queries (not including any DNS 954 redirection mechanisms which can increase the total number of 955 queries). This leads to two considerations: 957 1. An attacker can send a message to an ARC participant with a 958 concocted sequence of ARC Sets bearing the domains of intended 959 victims, and all of them will be queried by the participant until 960 a failure is discovered. The difficulty of forging the signature 961 values should limit the extent of this load to domains under 962 control of the attacker. Query traffic pattern analysis may 963 expose information about downstream validating ADMD 964 infrastructure. 966 2. DKIM only performs one DNS query per signature, while ARC can 967 introduce many (per chain). Absent caching, slow DNS responses 968 can cause SMTP timeouts; and backlogged delivery queues on 969 Validating systems. This could be exploited as a DoS attack. 971 9.3. Message Content Suspicion 973 Recipients are cautioned to treat messages bearing Authenticated 974 Received Chains with the same suspicion applied to all other 975 messages. This includes appropriate content scanning and other 976 checks for potentially malicious content. 978 Just as passing message authentication is not an indication of 979 message safety, forwarding that information through the mechanism of 980 ARC is also not an indication of message safety. Even if all ARC- 981 enabled ADMDs are trusted, ADMDs may have become compromised, may 982 miss unsafe content, or may not properly authenticate messages. 984 9.4. Message Sealer Suspicion 986 Recipients are cautioned to treat every Sealer of the ARC Chain with 987 suspicion. Just as with a validated DKIM signature, responsibility 988 for message handling is attributed to the signing domain, but whether 989 or not that signer is a malicious actor is out of scope of the 990 authentication mechanism. Since ARC aids message delivery in the 991 event of an authentication failure, ARC Sealers should be treated 992 with suspicion, so that a malicious actor cannot Seal spam or other 993 fraudulent messages to aid their delivery, too. 995 9.5. Replay Attacks 997 Since ARC inherits heavily from DKIM, it has similar attack vectors. 998 In particular, the Replay Attack described in [RFC6376] section 8.6 999 is potentially amplified by ARC's chained statuses. In an ARC replay 1000 attack, a malicious actor would take an intact and passing ARC Chain, 1001 and then resend it to many recipients without making any 1002 modifications that invalidate the latest AMS or AS. The impact to a 1003 receiver would be more DNS lookups and signature evaluations. This 1004 scope of this attack can be limited by caching DNS queries and 1005 following the same signing scope guidance from [RFC6376] section 1006 5.4.1. 1008 10. IANA Considerations 1010 [[ *Note to the RFC Editors:* dkim header.s is defined both here and 1011 in [I-D-7601bis]. Please delete the overlap from whichever document 1012 goes through the publication process after the other. ]] 1014 This draft introduces three new headers fields and updates the Email 1015 Authentication Parameters registry with one new authentication method 1016 and several status codes. 1018 10.1. Email Authentication Results Names Registry Update 1020 This draft adds one Auth Method with three Codes to the IANA "Email 1021 Authentication Result Names" registry: 1023 o Auth Method : arc Code: "none", "pass", "fail" Specification: 1024 [I-D.ARC] Section 2.2 Status: active 1026 10.2. Email Authentication Methods Registry Update 1028 This draft adds several new items to the Email Authentication Methods 1029 registry, most recently defined in [I-D-7601bis]: 1031 o Method: arc Definition: [I-D.ARC] ptype: smtp Property: client-ip 1032 Value: IP address of originating SMTP connection Status: active 1033 Version: 1 1035 o Method: arc Definition: [I-D.ARC] ptype: header Property: oldest- 1036 pass Value: The instance id of the oldest validating AMS, or 0 if 1037 they all pass (see Sectionn 4) Status: active Version: 1 1039 o Method: dkim Definition: [RFC6376] ptype: header Property: s 1040 Value: value of signature "s" tag Status: active Version: 1 1042 10.3. Definitions of the ARC header fields 1044 This specification adds three new header fields to the "Permanent 1045 Message Header Field Registry", as follows: 1047 o Header field name: ARC-Seal Applicable protocol: mail Status: 1048 draft Author/Change controller: IETF Specification document(s): 1049 [I-D.ARC] Related information: [RFC6376] 1051 o Header field name: ARC-Message-Signature Applicable protocol: mail 1052 Status: draft Author/Change controller: IETF Specification 1053 document(s): [I-D.ARC] Related information: [RFC6376] 1055 o Header field name: ARC-Authentication-Results Applicable protocol: 1056 mail Status: standard Author/Change controller: IETF Specification 1057 document(s): [I-D.ARC] Related information: [I-D-7601bis] 1059 11. Experimental Considerations 1061 The ARC protocol is designed to address common interoperability 1062 issues introduced by intermediate message handlers. Interoperability 1063 issues are described in [RFC6377] and [RFC7960]. 1065 As the ARC protocol is implemented by intermediary handlers over 1066 time, the following should be evaluated in order to determine the 1067 success of the protocol in accomplishing the intended benefits. 1069 11.1. Success Consideration 1071 In an attempt to deliver legitimate messages that users desire, many 1072 receivers use heuristic-based methods to identify messages that 1073 arrive via indirect delivery paths. 1075 ARC will be a success if the presence of Authenticated Received 1076 Chains allows for improved decision making when processing legitimate 1077 messages. 1079 11.2. Failure Considerations 1081 ARC should function without introducing significant new vectors for 1082 abuse (see Section Section 9). If unforseen vectors are enabled by 1083 ARC, then this protocol will be a failure. Note that weaknesses 1084 inherent in the mail protocols ARC is built upon (such as DKIM replay 1085 attacks and other known issues) are not new vectors which can be 1086 attributed to this specification. 1088 11.3. Open Questions 1090 The following open questions are academic and have no clear answer at 1091 the time of the development of the protocol. However, additional 1092 deployment should be able to gather the necessary data to answer some 1093 or all of them. 1095 11.3.1. Value of the ARC-Seal (AS) Header 1097 Data should be collected to show if the ARC-Seal (AS) provides value 1098 beyond the ARC Message Signature (AMS) for either making delivery 1099 decisions or catching malicious actors trying to craft or replay 1100 malicious chains. 1102 11.3.2. DNS Overhead 1104 Longer Authenticated Received Chains will require more queries to 1105 retrieve the keys for validating the chain. While this is not 1106 believed to be a security issue (see Section Section 9.2), it is 1107 unclear how much overhead will truly be added. This is similar to 1108 some of the initial processing and query load concerns which were 1109 debated at the time of the DKIM specification development. 1111 Data should be collected to better understand usable length and 1112 distribution of lengths found in valid Authenticated Received Chains 1113 along with the the DNS impact of processing Authenticated Received 1114 Chains. 1116 An effective operational maximum will have to be developed through 1117 deployment experience in the field. 1119 11.3.3. What Trace Information is Valuable 1121 There are several edge cases where the information in the AAR can 1122 make the difference between message delivery or rejection. For 1123 example, if there is a well known mailing list that seals with ARC 1124 but doesn't do its own initial DMARC enforcement, an Internet Mail 1125 Handler with this knowledge could make a delivery decision based upon 1126 the authentication information it sees in the corresponding AAR 1127 header. 1129 Certain trace information in the AAR is useful/necessary in the 1130 construction of DMARC reports. 1132 Certain receivers believe the entire set of trace information would 1133 be valuable to feed into machine learning systems to identify fraud 1134 and/or provide other signals related to message delivery. 1136 It is unclear what trace information will be valuable for all 1137 receivers, regardless of size. 1139 Data should be collected on what trace information receivers are 1140 using that provides useful signals that affect deliverability, and 1141 what portions of the trace data are left untouched or provide no 1142 useful information. 1144 Since many such systems are intentionally proprietary or confidential 1145 to prevent gaming by abusers, it may not be viable to reliably answer 1146 this particular question. The evolving nature of attacks can also 1147 shift the landscape of "useful" information over time. 1149 12. Implementation Status 1151 [[ Note to the RFC Editor: Please remove this section before 1152 publication along with the reference to [RFC6982]. ]] 1154 This section records the status of known implementations of the 1155 protocol defined by this specification at the time of posting of this 1156 Internet-Draft, and is based on a proposal described in [RFC6982]. 1157 The description of implementations in this section is intended to 1158 assist the IETF in its decision processes in progressing drafts to 1159 RFCs. Please note that the listing of any individual implementation 1160 here does not imply endorsement by the IETF. Furthermore, no effort 1161 has been spent to verify the information presented here that was 1162 supplied by IETF contributors. This is not intended as, and must not 1163 be construed to be, a catalog of available implementations or their 1164 features. Readers are advised to note that other implementations may 1165 exist. 1167 This information is known to be correct as of the eighth 1168 interoperability test event which was held on 2018-03-17 at IETF101. 1170 For a few of the implementations, later status information was 1171 available as of June 2018. 1173 12.1. GMail test reflector and incoming validation 1175 Organization: Google Description: Internal production implementation 1176 with both debug analysis and validating + sealing pass-through 1177 function Status of Operation: Production - Incoming Validation 1178 Coverage: Full spec implemented as of [ARC-DRAFT-14] Licensing: 1179 Proprietary - Internal only Implementation Notes: 1181 o Full functionality was demonstrated during the interop testing on 1182 2018-03-17. 1184 Contact Info: arc-discuss@dmarc.org [1] 1186 12.2. AOL test reflector and internal tagging 1188 Organization: AOL Description: Internal prototype implementation with 1189 both debug analysis and validating + sealing pass-through function 1190 Status of Operation: Beta Coverage: ARC Chain validity status 1191 checking is operational, but only applied to email addresses enrolled 1192 in the test program. This system conforms to [ARC-DRAFT-05] 1193 Licensing: Proprietary - Internal only Implementation Notes: 1195 o 2017-07-15: Full functionality verified during the interop 1196 testing. 1198 o 2018-06: Partially retired but still accessible by special request 1199 due to the in process evolution of the AOL mail infrastructure to 1200 the integrated OATH environment. The implementation was based on 1201 the Apache James DKIM code base and may be contributed back to 1202 that project in the future. 1204 Contact Info: arc-discuss@dmarc.org [2] 1206 12.3. dkimpy 1208 Organization: dkimpy developers/Scott Kitterman Description: Python 1209 DKIM package Status of Operation: Production Coverage: 1211 o 2017-07-15: The internal test suite is incomplete, but the command 1212 line developmental version of validator was demonstrated to 1213 interoperate with the Google and AOL implementations during the 1214 interop on 2017-07-15 and the released version passes the tests in 1215 [ARC-TEST] arc_test_suite [3] with both python and python3. 1217 Licensing: Open/Other (same as dkimpy package = BCD version 2) 1218 Contact Info: https://launchpad.net/dkimpy 1220 12.4. OpenARC 1222 Organization: TDP/Murray Kucherawy Description: Implemention of 1223 milter functionality related to the OpenDKIM and OpenDMARC packages 1224 Status of Operation: Beta Coverage: Built to support [ARC-DRAFT-14] 1225 Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) 1226 Implementation Notes: 1228 o The build is FreeBSD oriented but some packages have been built 1229 for easier deployment on RedHat-based Linux platforms. 1231 o Some issues still exist when deploying in a chained milter 1232 arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC) 1233 with coordination between the stages. When deployed in a 1234 "sandwich" configuration around an MLM, there is no effective 1235 mechanism to convey trust from the ingress (validator) to egress 1236 (signer) instances. (_NOTE_: this is expected to resolved with a 1237 new release of OpenDMARC expected in mid-2018.) 1239 Contact Info: arc-discuss@dmarc.org [4] 1241 12.5. Mailman 3.x patch 1243 Organization: Mailman development team Description: Integrated ARC 1244 capabilities within the Mailman 3.2 package Status of Operation: 1245 Patch submitted Coverage: Based on OpenARC Licensing: Same as mailman 1246 package - GPL Implementation Notes: 1248 o Appears to work properly in at least one beta deployment, but 1249 waiting on acceptance of the pull request into the mainline of 1250 mailman development 1252 Contact Info: https://www.gnu.org/software/mailman/contact.html 1254 12.6. Copernica/MailerQ web-based validation 1256 Organization: Copernica Description: Web-based validation of ARC- 1257 signed messages Status of Operation: Beta Coverage: Built to support 1258 [ARC-DRAFT-05] Licensing: On-line usage only Implementation Notes: 1260 o Released 2016-10-24 1262 o Requires full message content to be pasted into a web form found 1263 at http://arc.mailerq.com/ (warning - https is not supported). 1265 o An additional instance of an ARC signature can be added if one is 1266 willing to paste a private key into an unsecured web form. 1268 o 2017-07-15: Testing shows that results match the other 1269 implementations listed in this section. 1271 Contact Info: https://www.copernica.com/ 1273 12.7. Rspamd 1275 Organization: Rspamd community Description: ARC signing and 1276 verification module Status of Operation: Production, though 1277 deployment usage is unknown Coverage: Built to support [ARC-DRAFT-14] 1278 Licensing: Open source Implementation Notes: 1280 o 2017-06-12: Released with version 1.6.0 1282 o 2017-07-15: Testing during the interop showed that the validation 1283 functionality interoperated with the Google, AOL, dkimpy and 1284 MailerQ implementations 1286 Contact Info: https://rspamd.com/doc/modules/arc.html and 1287 https://github.com/vstakhov/rspamd 1289 12.8. PERL MAIL::DKIM module 1291 Organization: FastMail Description: Email domain authentication (sign 1292 and/or verify) module, previously included SPF / DKIM / DMARC, now 1293 has ARC added Status of Operation: Production, deployment usage 1294 unknown Coverage: Built to support [ARC-DRAFT-10] Licensing: Open 1295 Source Implementation Notes: 1297 o 2017-12-15: v0.50 released with full test set passing for ARC 1299 Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/ 1301 12.9. PERL Mail::Milter::Authentication module 1303 Organization: FastMail Description: Email domain authentication 1304 milter, uses MAIL::DKIM (see above) Status of Operation: Intial 1305 validation completed during IETF99 hackathon with some follow-on work 1306 during the week Coverage: Built to support [ARC-DRAFT-14] Licensing: 1307 Open Source Implementation Notes: 1309 o 2017-07-15: Validation functionality which interoperates with 1310 Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, 1311 the signing functionality was reported to be working 1313 o 2017-07-20: ARC functionality has not yet been pushed back to the 1314 github repo but should be showing up soon 1316 Contact Info: https://github.com/fastmail/authentication_milter 1318 12.10. Sympa List Manager 1320 Organization: Sympa Dev Community Description: Work in progress 1321 Status of Operation: Work in progress Coverage: unknown Licensing: 1322 open source Implementation Notes: 1324 o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/ 1325 issues/153 1327 Contact Info: https://github.com/sympa-community 1329 12.11. Oracle Messaging Server 1331 Organization: Oracle Description: Status of Operation: Intial 1332 development work during IETF99 hackathon. Framework code is 1333 complete, crypto functionality requires integration with libsodium 1334 Coverage: Work in progress Licensing: Unknown Implementation Notes: 1336 o 2018-03: Protocol handling components are completed, but crypto is 1337 not yet functional. 1339 Contact Info: Chris Newman, Oracle 1341 12.12. MessageSystems Momentum and PowerMTA platforms 1343 Organization: MessageSystems/SparkPost Description: OpenARC 1344 integration into the LUA-enabled Momentum processing space Status of 1345 Operation: Beta Coverage: Same as OpenARC Licensing: Unknown 1346 Implementation Notes: 1348 o Initial deployments for validation expected in mid-2018. 1350 Contact Info: TBD 1352 12.13. Exim 1354 Organization: Exim developers Status of Operation: Operational; 1355 requires specific enabling for compile. Coverage: Full spec 1356 implemented as of [ARC-DRAFT-13] Licensing: GPL Contact Info: exim- 1357 users@exim.org Implementation notes: 1359 o Exim 4.91 1361 13. References 1363 13.1. Normative References 1365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1366 Requirement Levels", BCP 14, RFC 2119, 1367 DOI 10.17487/RFC2119, March 1997, 1368 . 1370 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 1371 RFC 3463, DOI 10.17487/RFC3463, January 2003, 1372 . 1374 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1375 Specifications: ABNF", STD 68, RFC 5234, 1376 DOI 10.17487/RFC5234, January 2008, 1377 . 1379 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1380 DOI 10.17487/RFC5322, October 2008, 1381 . 1383 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1384 DOI 10.17487/RFC5598, July 2009, 1385 . 1387 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1388 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1389 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1390 . 1392 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1393 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 1394 September 2011, . 1396 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1397 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1398 DOI 10.17487/RFC7208, April 2014, 1399 . 1401 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1402 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1403 . 1405 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 1406 Message Authentication Status", RFC 7601, 1407 DOI 10.17487/RFC7601, August 2015, 1408 . 1410 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1411 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1412 May 2017, . 1414 13.2. Informative References 1416 [ARC-DRAFT-05] 1417 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1418 (I-D-05)", n.d., . 1421 [ARC-DRAFT-10] 1422 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1423 (I-D-10)", n.d., . 1426 [ARC-DRAFT-13] 1427 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1428 (I-D-13)", n.d., . 1431 [ARC-DRAFT-14] 1432 Andersen, K., "Authenticated Received Chain (ARC) Protocol 1433 (I-D-14)", n.d., . 1436 [ARC-MULTI] 1437 Andersen, K., "Using Multiple Signing Algorithms with 1438 ARC", January 2018, . 1441 [ARC-TEST] 1442 Blank, S., "ARC Test Suite", January 2017, 1443 . 1445 [ARC-USAGE] 1446 Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, 1447 "Recommended Usage of the ARC Headers", April 2018, 1448 . 1451 [ENHANCED-STATUS] 1452 "IANA SMTP Enhanced Status Codes", n.d., 1453 . 1456 [I-D-7601bis] 1457 Kucherawy, M., "Message Header Field for Indicating 1458 Message Authentication Status", February 2018, 1459 . 1462 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1463 Code: The Implementation Status Section", RFC 6982, 1464 DOI 10.17487/RFC6982, July 2013, 1465 . 1467 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1468 Message Authentication, Reporting, and Conformance 1469 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1470 . 1472 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 1473 E., Ed., and K. Andersen, Ed., "Interoperability Issues 1474 between Domain-based Message Authentication, Reporting, 1475 and Conformance (DMARC) and Indirect Email Flows", 1476 RFC 7960, DOI 10.17487/RFC7960, September 2016, 1477 . 1479 13.3. URIs 1481 [1] mailto:arc-discuss@dmarc.org 1483 [2] mailto:arc-discuss@dmarc.org 1485 [3] https://github.com/Valimail/arc_test_suite 1487 [4] mailto:arc-discuss@dmarc.org 1489 [5] https://trac.ietf.org/trac/dmarc/ticket/17 1491 [6] mailto:dmarc@ietf.org 1493 [7] mailto:arc-discuss@dmarc.org 1495 [8] mailto:arc-interop@dmarc.org 1497 [9] https://arc-spec.org 1499 Appendix A. Appendix A - Design Requirements 1501 [[ Note: This section is re-inserted for background information from 1502 early versions of the spec. ]] 1503 The specification of the ARC framework is driven by the following 1504 high-level goals, security considerations, and practical operational 1505 requirements. 1507 A.1. Primary Design Criteria 1509 o Provide a verifiable "chain of custody" for email messages; 1511 o Not require changes for originators of email; 1513 o Support the verification of the ARC header field set by each hop 1514 in the handling chain; 1516 o Work at Internet scale; and 1518 o Provide a trustable mechanism for the communication of 1519 Authentication-Results across trust boundaries. 1521 A.2. Out of Scope 1523 ARC is not a trust framework. Users of the ARC header fields are 1524 cautioned against making unsubstantiated conclusions when 1525 encountering a "broken" ARC sequence. 1527 Appendix B. Appendix B - Example Usage 1529 [[ Note: The following examples were mocked up early in the 1530 definition process for the spec. They no longer reflect the current 1531 definition and need various updates which will be included in a 1532 future draft. Issue 17 [5] ]] 1534 [[ Note: Need input from the WG as to what sort of sequence of 1535 examples would be considered useful - otherwise we'll just drop this 1536 section entirely. ]] 1538 1540 Appendix C. Acknowledgements 1542 This draft originated with the work of OAR-Dev Group. 1544 The authors thank all of the OAR-Dev group for the ongoing help and 1545 though-provoking discussions from all the participants, especially: 1546 Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck 1547 Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, 1548 Mike Jones, Steve Jones, Terry Zink, Tim Draegen. 1550 Grateful appreciation is extended to the people who provided feedback 1551 through the discuss mailing list. 1553 Appendix D. Comments and Feedback 1555 Please address all comments, discussions, and questions to 1556 dmarc@ietf.org [6]. Earlier discussions can be found at arc- 1557 discuss@dmarc.org [7]. Interop discussions planning can be found at 1558 arc-interop@dmarc.org [8]. 1560 Some introductory material for less technical people can be found at 1561 https://arc-spec.org [9]. 1563 Authors' Addresses 1565 Kurt Andersen 1566 LinkedIn 1567 1000 West Maude Ave 1568 Sunnyvale, California 94085 1569 USA 1571 Email: kurta@linkedin.com 1573 Brandon Long (editor) 1574 Google 1576 Email: blong@google.com 1578 Seth Blank (editor) 1579 Valimail 1581 Email: seth@valimail.com 1583 Murray Kucherawy (editor) 1584 TDP 1586 Email: superuser@gmail.com 1588 Tim Draegon (editor) 1589 dmarcian 1591 Email: tim@dmarcian.com