1
2
3
4
5
6
7Internet Engineering Task Force (IETF) K. Andersen
8Request for Comments: 8617 LinkedIn
9Category: Experimental B. Long, Ed.
10ISSN: 2070-1721 Google
11 S. Blank, Ed.
12 Valimail
13 M. Kucherawy, Ed.
14 TDP
15 July 2019
16
17
18 The Authenticated Received Chain (ARC) Protocol
19
20Abstract
21
22 The Authenticated Received Chain (ARC) protocol provides an
23 authenticated "chain of custody" for a message, allowing each entity
24 that handles the message to see what entities handled it before and
25 what the message's authentication assessment was at each step in the
26 handling.
27
28 ARC allows Internet Mail Handlers to attach assertions of message
29 authentication assessment to individual messages. As messages
30 traverse ARC-enabled Internet Mail Handlers, additional ARC
31 assertions can be attached to messages to form ordered sets of ARC
32 assertions that represent the authentication assessment at each step
33 of the message-handling paths.
34
35 ARC-enabled Internet Mail Handlers can process sets of ARC assertions
36 to inform message disposition decisions, identify Internet Mail
37 Handlers that might break existing authentication mechanisms, and
38 convey original authentication assessments across trust boundaries.
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58Andersen, et al. Experimental [Page 1]
59
60RFC 8617 The ARC Protocol July 2019
61
62
63Status of This Memo
64
65 This document is not an Internet Standards Track specification; it is
66 published for examination, experimental implementation, and
67 evaluation.
68
69 This document defines an Experimental Protocol for the Internet
70 community. This document is a product of the Internet Engineering
71 Task Force (IETF). It represents the consensus of the IETF
72 community. It has received public review and has been approved for
73 publication by the Internet Engineering Steering Group (IESG). Not
74 all documents approved by the IESG are candidates for any level of
75 Internet Standard; see Section 2 of RFC 7841.
76
77 Information about the current status of this document, any errata,
78 and how to provide feedback on it may be obtained at
79 https://www.rfc-editor.org/info/rfc8617.
80
81Copyright Notice
82
83 Copyright (c) 2019 IETF Trust and the persons identified as the
84 document authors. All rights reserved.
85
86 This document is subject to BCP 78 and the IETF Trust's Legal
87 Provisions Relating to IETF Documents
88 (https://trustee.ietf.org/license-info) in effect on the date of
89 publication of this document. Please review these documents
90 carefully, as they describe your rights and restrictions with respect
91 to this document. Code Components extracted from this document must
92 include Simplified BSD License text as described in Section 4.e of
93 the Trust Legal Provisions and are provided without warranty as
94 described in the Simplified BSD License.
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114Andersen, et al. Experimental [Page 2]
115
116RFC 8617 The ARC Protocol July 2019
117
118
119Table of Contents
120
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
122 2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5
123 2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5
124 2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5
125 2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 6
126 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 6
127 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
128 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 7
129 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7
130 3.3. Internet Mail Handlers / Intermediaries . . . . . . . . . 7
131 3.4. Authentication Assessment . . . . . . . . . . . . . . . . 7
132 3.5. Signing vs. Sealing . . . . . . . . . . . . . . . . . . . 8
133 3.6. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 8
134 3.7. Validator . . . . . . . . . . . . . . . . . . . . . . . . 8
135 3.8. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 8
136 3.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
137 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9
138 4.1. ARC Header Fields . . . . . . . . . . . . . . . . . . . . 9
139 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 9
140 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 9
141 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 11
142 4.1.4. Internationalized Email (EAI) . . . . . . . . . . . . 12
143 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 12
144 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 12
145 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 13
146 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 13
147 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 14
148 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 14
149 5.1.1. Header Fields to Include in ARC-Seal Signatures . . . 15
150 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 15
151 5.1.3. Only One Authenticated Received Chain per Message . . 16
152 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 16
153 5.1.5. Sealing Is Always Safe . . . . . . . . . . . . . . . 16
154 5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 17
155 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 18
156 5.2.2. Responding to ARC Validation Failures during the SMTP
157 Transaction . . . . . . . . . . . . . . . . . . . . . 19
158 6. Communication of Validation Results . . . . . . . . . . . . . 19
159 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19
160 7.1. Communicate Authentication Assessment across Trust
161 Boundaries . . . . . . . . . . . . . . . . . . . . . . . 19
162 7.1.1. Message-Scanning Services . . . . . . . . . . . . . . 20
163 7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 20
164 7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 20
165 7.2. Inform Message Disposition Decisions . . . . . . . . . . 21
166 7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 21
167
168
169
170Andersen, et al. Experimental [Page 3]
171
172RFC 8617 The ARC Protocol July 2019
173
174
175 7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 22
176 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
177 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
178 9.1. Increased Header Field Size . . . . . . . . . . . . . . . 23
179 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 23
180 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 24
181 9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 24
182 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 24
183 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
184 10.1. Update to Email Authentication Result Names Registry . . 25
185 10.2. Update to Email Authentication Methods Registry . . . . 25
186 10.3. New Header Fields in Permanent Message Header Field
187 Registry . . . . . . . . . . . . . . . . . . . . . . . . 26
188 10.4. New Status Code in Enumerated Status Codes Registry . . 26
189 11. Experimental Considerations . . . . . . . . . . . . . . . . . 27
190 11.1. Success Consideration . . . . . . . . . . . . . . . . . 27
191 11.2. Failure Considerations . . . . . . . . . . . . . . . . . 27
192 11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 27
193 11.3.1. Value of the ARC-Seal (AS) Header Field . . . . . . 27
194 11.3.2. Usage and/or Signals from Multiple Selectors and/or
195 Domains in ARC Sets . . . . . . . . . . . . . . . . 28
196 11.3.3. DNS Overhead . . . . . . . . . . . . . . . . . . . . 28
197 11.3.4. What Trace Information Is Valuable? . . . . . . . . 28
198 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
199 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
200 12.2. Informative References . . . . . . . . . . . . . . . . . 30
201 Appendix A. Design Requirements . . . . . . . . . . . . . . . . 32
202 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 32
203 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 32
204 Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 32
205 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35
206 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
207
2081. Introduction
209
210 The utility of widely deployed email authentication technologies such
211 as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
212 Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
213 by intermediate handlers. This impact is thoroughly documented in
214 the defining documents for SPF and DKIM and further discussed in
215 [RFC6377] and [RFC7960].
216
217 Domain-based Message Authentication, Reporting, and Conformance
218 (DMARC) [RFC7489] also relies upon SPF and DKIM authentication
219 mechanisms. Failures of authentication caused by the actions of
220 intermediate handlers can cause legitimate mail to be incorrectly
221 rejected or misdirected.
222
223
224
225
226Andersen, et al. Experimental [Page 4]
227
228RFC 8617 The ARC Protocol July 2019
229
230
231 Authenticated Received Chain (ARC) creates a mechanism for individual
232 Internet Mail Handlers to add their authentication assessment to a
233 message's ordered set of handling results. ARC encapsulates the
234 authentication assessment in a DKIM signature derivative to grant
235 other handlers the ability to verify the authenticity of the
236 individual assessment assertion as well as the aggregate set and
237 sequence of results.
238
239 Ordered sets of authentication assessments can be used by ARC-enabled
240 Internet Mail Handlers to inform message-handling disposition,
241 identify where alteration of message content might have occurred, and
242 provide additional trace information for use in understanding
243 message-handling paths.
244
2452. General Concepts
246
247 ARC is loosely based on concepts from evidence collection. Evidence
248 is usually collected, labeled, stored, and transported in specific
249 ways to preserve the state of evidence and to document all processing
250 steps.
251
2522.1. Evidence
253
254 In ARC's situation, the "evidence" is a message's authentication
255 assessment at any point along the delivery path between origination
256 and final delivery. Determination of message authentication can be
257 affected when intermediate handlers modify message content (header
258 fields and/or body content), route messages through unforeseen paths,
259 or change envelope information.
260
261 The authentication assessment for a message is determined upon
262 receipt of a message and documented in the Authentication-Results
263 header field(s). ARC extends this mechanism to survive transit
264 through intermediary Administrative Management Domains (ADMDs).
265
266 Because the first-hand determination of an authentication assessment
267 can never be reproduced by other handlers, the assertion of the
268 authentication assessment is more akin to testimony by a verifiable
269 party than to hard evidence, which can be independently evaluated.
270
2712.2. Custody
272
273 "Custody" refers to when an Internet Mail Handler processes a
274 message. When a handler takes custody of a message, the handler
275 becomes a custodian and attaches its own evidence (authentication
276 assessment upon receipt) to the message if it is ARC enabled.
277 Evidence is added in such a way that future handlers can verify the
278 authenticity of both evidence and custody.
279
280
281
282Andersen, et al. Experimental [Page 5]
283
284RFC 8617 The ARC Protocol July 2019
285
286
2872.3. Chain of Custody
288
289 The "chain of custody" of ARC is the entire set of evidence and
290 custody that travels with a message.
291
2922.4. Validation of Chain of Custody
293
294 Any ARC-enabled Internet Mail Handler can validate the entire set of
295 custody and the authentication assessments asserted by each party to
296 yield a valid chain of custody. If the evidence-supplying custodians
297 can be trusted, then the validated chain of custody describes the
298 (possibly changing) authentication assessment as the message traveled
299 through various custodians.
300
301 Even though a message's authentication assessment might have changed,
302 the validated chain of custody can be used to determine if the
303 changes (and the custodians responsible for the changes) can be
304 tolerated.
305
3063. Terminology and Definitions
307
308 This section defines terms used in the rest of the document.
309
310 Readers should to be familiar with the contents, core concepts, and
311 definitions found in [RFC5598]. The potential roles of transit
312 services in the delivery of email are directly relevant.
313
314 Language, syntax (including some ABNF constructs), and concepts are
315 imported from DKIM [RFC6376]. Specific references to DKIM are made
316 throughout this document. The following terms are imported from
317 [RFC5598]:
318
319 o Administrative Management Domain (ADMD), Section 2.3
320
321 o Message Transfer Agent (MTA), Section 4.3.2
322
323 o Message Submission Agent (MSA), Section 4.3.1
324
325 o Message Delivery Agent (MDA), Section 4.3.3
326
327 Syntax descriptions use ABNF [RFC5234] [RFC7405].
328
329 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
330 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
331 "OPTIONAL" in this document are to be interpreted as described in
332 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
333 capitals, as shown here.
334
335
336
337
338Andersen, et al. Experimental [Page 6]
339
340RFC 8617 The ARC Protocol July 2019
341
342
3433.1. ARC Set
344
345 Section 4.1 introduces three (3) ARC header fields that are added to
346 a message by an ARC-enabled Internet Mail Handler. Together, these
347 three header fields compose a single "ARC Set". An ARC Set provides
348 the means for an Internet Mail Handler to attach an authentication
349 assessment to a message in a manner that can be verified by future
350 handlers. A single message can contain multiple ARC Sets.
351
352 In general concept terms, an ARC Set represents Evidence and Custody.
353
3543.2. Authenticated Received Chain (ARC)
355
356 The sequence of ARC Sets attached to a message at a given time is
357 called the "Authenticated Received Chain" or "ARC". An Authenticated
358 Received Chain is the record of individual authentication assessments
359 as a message traverses through ARC-participating ADMDs.
360
361 The first attachment of an ARC Set to a message causes an
362 Authenticated Received Chain to be created. Additional attachments
363 of ARC Sets cause the Authenticated Received Chain to be extended.
364
365 In general concept terms, an Authenticated Received Chain represents
366 a chain of custody.
367
3683.3. Internet Mail Handlers / Intermediaries
369
370 Internet Mail Handlers process and deliver messages across the
371 Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as
372 defined in [RFC5598].
373
374 Throughout this document, the term "intermediaries" refers to both
375 regular MTAs as well as delivery/reposting agents such as mailing
376 lists covered within the scope of transit services per [RFC5598].
377
378 "Intermediaries" and "Internet Mail Handlers" are used synonymously
379 throughout this document.
380
3813.4. Authentication Assessment
382
383 The authentication assessment that is affixed to a message as part of
384 each ARC Set consists of the "authres-payload" [RFC8601]. For the
385 integrity of an ARC Set, the authentication assessment only needs to
386 be properly encapsulated within the ARC Set as defined in
387 Section 4.1. The accuracy or syntax of the authres-payload field
388 does not affect the validity of the ARC Chain itself.
389
390
391
392
393
394Andersen, et al. Experimental [Page 7]
395
396RFC 8617 The ARC Protocol July 2019
397
398
3993.5. Signing vs. Sealing
400
401 Signing is the process of affixing a digital signature to a message
402 as a header field, such as when a DKIM-Signature (as in [RFC6376],
403 Section 2.1), an AMS, or an AS is added. Sealing is when an ADMD
404 affixes a complete and valid ARC Set to a message to create or
405 continue an Authenticated Received Chain.
406
4073.6. Sealer
408
409 A Sealer is an Internet Mail Handler that attaches a complete and
410 valid ARC Set to a message.
411
412 In general concept terms, a Sealer adds its testimony (assertion of
413 authentication assessment) and proof of custody to the chain of
414 custody.
415
4163.7. Validator
417
418 A Validator is an ARC-enabled Internet Mail Handler that evaluates an
419 Authenticated Received Chain for validity and content. The process
420 of evaluation of the individual ARC Sets that compose an
421 Authenticated Received Chain is described in Section 5.2.
422
423 In general concept terms, a Validator inspects the chain of custody
424 to determine the content and validity of individual evidence supplied
425 by custodians.
426
4273.8. Imported ABNF Tokens
428
429 The following ABNF tokens are imported:
430
431 o tag-list ([RFC6376], Section 3.2)
432
433 o authres-payload ([RFC8601], Section 2.2)
434
435 o CFWS ([RFC5322], Section 3.2.2)
436
4373.9. Common ABNF Tokens
438
439 The following ABNF tokens are used elsewhere in this document:
440
441 position = 1*2DIGIT ; 1 - 50
442 instance = [CFWS] %s"i" [CFWS] "="
443 [CFWS] position
444 chain-status = ("none" / "fail" / "pass")
445 seal-cv-tag = %s"cv" [CFWS] "="
446 [CFWS] chain-status
447
448
449
450Andersen, et al. Experimental [Page 8]
451
452RFC 8617 The ARC Protocol July 2019
453
454
4554. Protocol Elements
456
4574.1. ARC Header Fields
458
459 ARC introduces three new header fields. The syntax for new header
460 fields adapts existing specifications. This document only describes
461 where ARC-specific changes in syntax and semantics differ from
462 existing specifications.
463
4644.1.1. ARC-Authentication-Results (AAR)
465
466 The ARC-Authentication-Results (AAR) header field records the message
467 authentication assessment as processed by an ARC-participating ADMD
468 at message arrival time.
469
470 In general concept terms, the AAR header field is where evidence is
471 recorded by a custodian.
472
473 The AAR header field is similar in syntax and semantics to an
474 Authentication-Results field [RFC8601], with two (2) differences:
475
476 o the name of the header field itself and
477
478 o the presence of the instance tag. Additional information on the
479 instance tag can be found in Section 4.2.1.
480
481 The formal ABNF for the AAR header field is:
482
483 arc-info = instance [CFWS] ";" authres-payload
484 arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
485
486 Because there is only one AAR allowed per ARC Set, the AAR MUST
487 contain the combined authres-payload with all of the authentication
488 results from within the participating ADMD, regardless of how many
489 Authentication-Results header fields are attached to the message.
490
4914.1.2. ARC-Message-Signature (AMS)
492
493 The ARC-Message-Signature (AMS) header field allows an ARC-
494 participating ADMD to convey some responsibility (custodianship) for
495 a message and possible message modifications to future ARC-
496 participating custodians.
497
498 In general concept terms, the AMS header field identifies a
499 custodian.
500
501
502
503
504
505
506Andersen, et al. Experimental [Page 9]
507
508RFC 8617 The ARC Protocol July 2019
509
510
511 The AMS header field has the same syntax and semantics as the DKIM-
512 Signature field [RFC6376], with three (3) differences:
513
514 o the name of the header field itself;
515
516 o no version tag ("v") is defined for the AMS header field. As
517 required for undefined tags (in [RFC6376]), if seen, a version tag
518 MUST be ignored; and
519
520 o the "i" (Agent or User Identifier (AUID)) tag is not imported from
521 DKIM; instead, this tag is replaced by the instance tag as defined
522 in Section 4.2.1.
523
524 ARC places no requirements on the selectors and/or domains used for
525 the AMS header field signatures.
526
527 The formal ABNF for the AMS header field is:
528
529 arc-ams-info = instance [CFWS] ";" tag-list
530 arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info
531
532 To reduce the chances of accidental invalidation of AMS signatures:
533
534 o AMS header fields are added by ARC-participating ADMDs as messages
535 exit the ADMD. AMS header fields SHOULD be attached so that any
536 modifications made by the ADMD are included in the signature of
537 the AMS header field.
538
539 o Authentication-Results header fields MUST NOT be included in AMS
540 signatures as they are likely to be deleted by downstream ADMDs
541 (per [RFC8601], Section 5).
542
543 o ARC-related header fields (ARC-Authentication-Results, ARC-
544 Message-Signature, and ARC-Seal) MUST NOT be included in the list
545 of header fields covered by the signature of the AMS header field.
546
547 To preserve the ability to verify the integrity of a message, the
548 signature of the AMS header field SHOULD include any DKIM-Signature
549 header fields already present in the message.
550
551
552
553
554
555
556
557
558
559
560
561
562Andersen, et al. Experimental [Page 10]
563
564RFC 8617 The ARC Protocol July 2019
565
566
5674.1.3. ARC-Seal (AS)
568
569 The AS header field permits ARC-participating ADMDs to verify the
570 integrity of AAR header fields and corresponding AMS header fields.
571
572 In general concept terms, the AS header field is how custodians bind
573 their authentication assessments (testimonials) into a chain of
574 custody so that Validators can inspect individual evidence and
575 custodians.
576
577 The AS header field is similar in syntax and semantics to DKIM-
578 Signature header fields [RFC6376], with the following differences:
579
580 o the "i" (AUID) tag is not imported from DKIM; instead, this tag is
581 replaced by the instance tag as defined in Section 4.2.1;
582
583 o the signature of the AS header field does not cover the body of
584 the message; therefore, there is no "bh" tag. The signature of
585 the AS header field only covers specific header fields as defined
586 in Section 5.1.1;
587
588 o no body canonicalization is performed as the AS signature does not
589 cover the body of a message;
590
591 o only "relaxed" header field canonicalization ([RFC6376],
592 Section 3.4.2) is used;
593
594 o the only supported tags are "i" (from Section 4.2.1 of this
595 document), and "a", "b", "d", "s", and "t" from [RFC6376],
596 Section 3.5. Note especially that the DKIM "h" tag is NOT allowed
597 and, if found, MUST result in a cv status of "fail" (for more
598 information, see Section 5.1.1); and
599
600 o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF
601 definition), is used to communicate the Chain Validation Status to
602 subsequent ADMDs.
603
604 ARC places no requirements on the selectors and/or domains used for
605 the AS header field signatures.
606
607 The formal ABNF for the AS header field is:
608
609 arc-as-info = instance [CFWS] ";" tag-list
610 arc-seal = "ARC-Seal:" [CFWS] arc-as-info
611
612
613
614
615
616
617
618Andersen, et al. Experimental [Page 11]
619
620RFC 8617 The ARC Protocol July 2019
621
622
6234.1.4. Internationalized Email (EAI)
624
625 In internationalized messages [RFC6532], many header fields can
626 contain UTF-8 as well as ASCII text. The changes for EAI are all
627 inherited from DKIM as updated by [RFC8616] and Authentication-
628 Results (A-R) as updated in [RFC8601], but they are called out here
629 for emphasis.
630
631 In all ARC header fields, the d= and s= tags can contain U-labels.
632 In all tags, non-ASCII characters need not be quoted in dkim-quoted-
633 printable.
634
635 The AAR header allows UTF-8 in the same places that Authentication-
636 Results does, as described in [RFC8601].
637
6384.2. ARC Set
639
640 An "ARC Set" is a single collection of three ARC header fields (AAR,
641 AMS, and AS). ARC header fields of an ARC Set share the same
642 "instance" value.
643
644 By adding all ARC header fields to a message, an ARC Sealer adds an
645 ARC Set to a message. A description of how Sealers add an ARC Set to
646 a message is found in Section 5.1.
647
6484.2.1. Instance Tags
649
650 Instance tags describe which ARC header fields belong to an ARC Set.
651 Each ARC header field of an ARC Set shares the same instance tag
652 value.
653
654 Instance tag values are integers that begin at 1 and are incremented
655 by each addition of an ARC Set. Through the incremental values of
656 instance tags, an ARC Validator can determine the order in which ARC
657 Sets were added to a message.
658
659 Instance tag values can range from 1-50 (inclusive).
660
661 _INFORMATIONAL_: The upper limit of 50 was picked based on some
662 initial observations reported by early working group members. The
663 value was chosen to balance the risk of excessive header field growth
664 (see Section 9.1) against expert opinion regarding the probability of
665 long-tail, but non-looping, multiple-intermediary mail flows. Longer
666 ARC Chains will also impose a load on Validators and DNS to support
667 additional verification steps. Observed quantities of "Received"
668 header fields were also considered in establishing this as an
669 experimental initial value.
670
671
672
673
674Andersen, et al. Experimental [Page 12]
675
676RFC 8617 The ARC Protocol July 2019
677
678
679 Valid ARC Sets MUST have exactly one instance of each ARC header
680 field (AAR, AMS, and AS) for a given instance value and signing
681 algorithm.
682
683 For handling multiple signing algorithms, see [ARC-MULTI].
684
6854.3. Authenticated Received Chain
686
687 An Authenticated Received Chain is an ordered collection of ARC Sets.
688 As ARC Sets are enumerated sets of ARC header fields, an
689 Authenticated Received Chain represents the output of message
690 authentication assessments along the handling path of ARC-enabled
691 processors.
692
693 Authentication assessments determined at each step of the ARC-enabled
694 handling path are present in an Authenticated Received Chain in the
695 form of AAR header fields. The ability to verify the identity of
696 message handlers and the integrity of message content is provided by
697 AMS header fields. AS header fields allow message handlers to
698 validate the assertions, order, and sequence of the Authenticated
699 Received Chain itself.
700
701 In general concept terms, an Authenticated Received Chain represents
702 a message's chain of custody. Validators can consult a message's
703 chain of custody to gain insight regarding each custodian of a
704 message and the evidence collected by each custodian.
705
7064.4. Chain Validation Status
707
708 The state of the Authenticated Received Chain at a specific
709 processing step is called the "Chain Validation Status". Chain
710 Validation Status information is communicated in several ways:
711
712 o as the AS header field in the "cv" tag and
713
714 o as part of the Authentication-Results and AAR header field(s).
715
716 Chain Validation Status has one of three possible values:
717
718 o none: There was no Authenticated Received Chain on the message
719 when it arrived for validation. Typically, this occurs when a
720 message is received directly from a message's original Message
721 Transfer Agent (MTA) or Message Submission Agent (MSA), or from an
722 upstream Internet Mail Handler that is not participating in ARC
723 handling.
724
725 o fail: The message contains an Authenticated Received Chain whose
726 validation failed.
727
728
729
730Andersen, et al. Experimental [Page 13]
731
732RFC 8617 The ARC Protocol July 2019
733
734
735 o pass: The message contains an Authenticated Received Chain whose
736 validation succeeded.
737
7385. Protocol Actions
739
740 ARC-enabled Internet Mail Handlers generally act as both ARC
741 Validators (when receiving messages) and ARC Sealers (when sending
742 messages onward, not originated locally).
743
744 An Authenticated Received Chain with a Chain Validation Status of
745 "pass" (or "none") allows Internet Mail Handlers to ascertain:
746
747 o all ARC-participating ADMDs that claim responsibility for handling
748 (and possibly modifying) the message in transit and
749
750 o the authentication assessments of the message as determined by
751 each ADMD (from AAR header fields).
752
753 With this information, Internet Mail Handlers MAY inform local policy
754 decisions regarding disposition of messages that experience
755 authentication failure due to intermediate processing.
756
7575.1. Sealer Actions
758
759 To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC
760 header fields AAR, AMS, and AS) to a message. All ARC header fields
761 in an ARC Set share the same instance tag value.
762
763 To perform sealing (aka to build and attach a new ARC Set), the
764 following actions must be taken by an ARC Sealer when presented with
765 a message:
766
767 1. All message modifications (including adding a DKIM-Signature
768 header field(s)) MUST be performed before sealing.
769
770 2. If the message already contains an Authenticated Received Chain
771 with the most recent AS reporting "cv=fail", there is no need to
772 proceed and the algorithm stops here.
773
774 3. Calculate the instance value. If the message already contains an
775 Authenticated Received Chain, the instance value is 1 more than
776 the highest instance number found in the Authenticated Received
777 Chain. If no Authenticated Received Chain exists, the instance
778 value is 1.
779
780
781
782
783
784
785
786Andersen, et al. Experimental [Page 14]
787
788RFC 8617 The ARC Protocol July 2019
789
790
791 4. Using the calculated instance value, generate and attach a
792 complete ARC Set to the message as follows:
793
794 A. Generate and attach an ARC-Authentication-Results header
795 field as defined in Section 4.1.1.
796
797 B. Generate and attach an ARC-Message-Signature header field as
798 defined in Section 4.1.2.
799
800 C. Generate and attach an ARC-Seal header field using the AS
801 definition found in Section 4.1.3, the prescribed headers
802 defined in Section 5.1.1, and the Chain Validation Status as
803 determined during ARC validation.
804
8055.1.1. Header Fields to Include in ARC-Seal Signatures
806
807 The ARC-Seal is generated in a manner similar to how DKIM-Signature
808 header fields are added to messages ([RFC6376], Section 3.7), with
809 explicit requirements on the header fields and ordering of those
810 fields.
811
812 The signature of an AS header field signs a canonicalized form of the
813 ARC Set header field values. The ARC Set header field values are
814 supplied to the hash function in increasing instance order, starting
815 at 1, and include the ARC Set being added at the time of sealing the
816 message.
817
818 Within an ARC Set, header fields are supplied to the hash function in
819 the following order:
820
821 1. ARC-Authentication-Results
822
823 2. ARC-Message-Signature
824
825 3. ARC-Seal
826
827 Note that when an Authenticated Received Chain has failed validation,
828 the signing scope for the ARC-Seal is modified as specified in
829 Section 5.1.2.
830
8315.1.2. Marking and Sealing "cv=fail" (Invalid) Chains
832
833 In the case of a failed Authenticated Received Chain, the header
834 fields included in the signature scope of the AS header field b=
835 value MUST only include the ARC Set header fields created by the MTA
836 that detected the malformed chain, as if this newest ARC Set was the
837 only set present.
838
839
840
841
842Andersen, et al. Experimental [Page 15]
843
844RFC 8617 The ARC Protocol July 2019
845
846
847 _INFORMATIONAL_: This approach is mandated to handle the case of a
848 malformed or otherwise invalid Authenticated Received Chain. There
849 is no way to generate a deterministic set of AS header fields
850 (Section 5.1.1) in most cases of invalid chains.
851
8525.1.3. Only One Authenticated Received Chain per Message
853
854 A message can have only one Authenticated Received Chain on it at a
855 time. Once broken, the chain cannot be continued, as the chain of
856 custody is no longer valid, and responsibility for the message has
857 been lost. For further discussion of this topic and the design
858 restriction that prevents chain continuation or re-establishment, see
859 [ARC-USAGE].
860
8615.1.4. Broad Ability to Seal
862
863 ARC is not solely intended for perimeter MTAs. Any Internet Mail
864 Handler MAY seal a message by adding a complete ARC Set, whether or
865 not they have modified or are aware of having modified the message.
866 For additional information, see Section 7.1.
867
8685.1.5. Sealing Is Always Safe
869
870 The utility of an Authenticated Received Chain is limited to very
871 specific cases. Authenticated Received Chains are designed to
872 provide additional information to an Internet Mail Handler when
873 evaluating messages for delivery in the context of authentication
874 failures. Specifically:
875
876 o Properly adding an ARC Set to a message does not damage or
877 invalidate an existing Authenticated Received Chain.
878
879 o Sealing an Authenticated Received Chain when a message has not
880 been modified does not negatively affect the chain.
881
882 o Validating a message exposes no new threat vectors (see
883 Section 9).
884
885 o An ADMD may choose to seal all inbound messages whether or not a
886 message has been modified or will be retransmitted.
887
888
889
890
891
892
893
894
895
896
897
898Andersen, et al. Experimental [Page 16]
899
900RFC 8617 The ARC Protocol July 2019
901
902
9035.2. Validator Actions
904
905 A Validator performs the following steps, in sequence, to process an
906 Authenticated Received Chain. Canonicalization, hash functions, and
907 signature validation methods are imported from [RFC6376], Section 5.
908
909 1. Collect all ARC Sets currently attached to the message.
910
911 * If there are none, the Chain Validation Status is "none", and
912 the algorithm stops here.
913
914 * The maximum number of ARC Sets that can be attached to a
915 message is 50. If more than the maximum number exist, the
916 Chain Validation Status is "fail", and the algorithm stops
917 here.
918
919 * In the following algorithm, the maximum discovered ARC
920 instance value is referred to as "N".
921
922 2. If the Chain Validation Status of the highest instance value ARC
923 Set is "fail", then the Chain Validation Status is "fail", and
924 the algorithm stops here.
925
926 3. Validate the structure of the Authenticated Received Chain. A
927 valid ARC has the following conditions:
928
929 A. Each ARC Set MUST contain exactly one each of the three ARC
930 header fields (AAR, AMS, and AS).
931
932 B. The instance values of the ARC Sets MUST form a continuous
933 sequence from 1..N with no gaps or repetition.
934
935 C. The "cv" value for all ARC-Seal header fields MUST NOT be
936 "fail". For ARC Sets with instance values > 1, the values
937 MUST be "pass". For the ARC Set with instance value = 1, the
938 value MUST be "none".
939
940 * If any of these conditions are not met, the Chain Validation
941 Status is "fail", and the algorithm stops here.
942
943 4. Validate the AMS with the greatest instance value (most recent).
944 If validation fails, then the Chain Validation Status is "fail",
945 and the algorithm stops here.
946
947
948
949
950
951
952
953
954Andersen, et al. Experimental [Page 17]
955
956RFC 8617 The ARC Protocol July 2019
957
958
959 5. _OPTIONAL_: Determine the "oldest-pass" value from the ARC Set by
960 validating each prior AMS beginning with N-1 and proceeding in
961 decreasing order to the AMS with the instance value of 1:
962
963 A. If an AMS fails to validate (for instance value "M"), then
964 set the oldest-pass value to the lowest AMS instance value
965 that passed (M+1), and go to the next step (there is no need
966 to check any other (older) AMS header fields). This does not
967 affect the validity of the Authenticated Received Chain.
968
969 B. If all AMS header fields verify, set the oldest-pass value to
970 zero (0).
971
972 6. Validate each AS beginning with the greatest instance value and
973 proceeding in decreasing order to the AS with the instance value
974 of 1. If any AS fails to validate, the Chain Validation Status
975 is "fail", and the algorithm stops here.
976
977 7. If the algorithm reaches this step, then the Chain Validation
978 Status is "pass", and the algorithm is complete.
979
980 The end result of this validation algorithm SHOULD be included within
981 the Authentication-Results header field for the ADMD.
982
983 As with a DKIM signature ([RFC6376], Section 6.3) that fails
984 verification, a message with an Authenticated Received Chain with a
985 Chain Validation Status of "fail" MUST be treated the same as a
986 message with no Authenticated Received Chain.
987
988 _INFORMATIONAL_: Recipients of an invalid or failing Authenticated
989 Received Chain can use that information as part of a wider handling
990 context. ARC adoption cannot be assumed by intermediaries; many
991 intermediaries will continue to modify messages without adding ARC
992 seals.
993
9945.2.1. All Failures Are Permanent
995
996 Authenticated Received Chains represent the traversal of messages
997 through one or more intermediaries. All errors, including DNS
998 failures, become unrecoverable and are considered permanent.
999
1000 Any error validating an Authenticated Received Chain results in a
1001 Chain Validation Status of "fail". For further discussion of this
1002 topic and the design restriction that prevents chain continuation or
1003 re-establishment, see [ARC-USAGE].
1004
1005
1006
1007
1008
1009
1010Andersen, et al. Experimental [Page 18]
1011
1012RFC 8617 The ARC Protocol July 2019
1013
1014
10155.2.2. Responding to ARC Validation Failures during the SMTP
1016 Transaction
1017
1018 If an ARC Validator determines that the incoming message fails ARC
1019 validation, the Validator MAY signal the breakage through the
1020 extended SMTP response code 5.7.29 ("ARC validation failure") and the
1021 corresponding SMTP basic response code. Because ARC failures are
1022 likely only to be detected in the context of other underlying
1023 authentication mechanism failures, Validators MAY use the more
1024 general 5.7.26 ("Multiple authentication checks failed") instead of
1025 the ARC-specific code.
1026
10276. Communication of Validation Results
1028
1029 Chain Validation Status (described in Section 4.4) is communicated
1030 via Authentication-Results (and AAR) header fields using the
1031 authentication method "arc". This authentication method is described
1032 in Section 10.1.
1033
1034 If necessary data is available, the ptypes and properties defined in
1035 Section 10.2 SHOULD be recorded in an Authentication-Results header
1036 field:
1037
1038 o smtp.remote-ip - The address of the connection-initiating SMTP
1039 server, from which the message is being relayed.
1040
1041 o header.oldest-pass - The instance number of the oldest AMS that
1042 still validates, or 0 if all pass.
1043
10447. Use Cases
1045
1046 This section explores several message handling use cases that are
1047 addressed by ARC.
1048
10497.1. Communicate Authentication Assessment across Trust Boundaries
1050
1051 When an intermediary ADMD adds an ARC Set to a message's
1052 Authenticated Received Chain (or creates the initial ARC Set), the
1053 ADMD communicates its authentication assessment to the next ARC-
1054 participating ADMD in the message-handling path.
1055
1056 If ARC-enabled ADMDs are trusted, Authenticated Received Chains can
1057 be used to bridge administrative boundaries.
1058
1059
1060
1061
1062
1063
1064
1065
1066Andersen, et al. Experimental [Page 19]
1067
1068RFC 8617 The ARC Protocol July 2019
1069
1070
10717.1.1. Message-Scanning Services
1072
1073 Message services are available to perform anti-spam, anti-malware,
1074 and anti-phishing scanning. Such services typically remove malicious
1075 content, replace HTTP links in messages with sanitized links, and/or
1076 attach footers to messages advertising the abilities of the message-
1077 scanning service. These modifications almost always break signature-
1078 based authentication (such as DKIM).
1079
1080 Scanning services typically require clients to point MX records of an
1081 Internet domain to the scanning service. Messages destined for the
1082 Internet domain are initially delivered to the scanning service.
1083 Once scanning is performed, messages are then routed to the client's
1084 own mail-handling infrastructure. Rerouting messages in this way
1085 almost always breaks path-based authentication (such as SPF).
1086
1087 Message-scanning services can attach Authenticated Received Chains to
1088 messages to communicate authentication assessment into client ADMDs.
1089 Clients can then benefit from the message-scanning service while
1090 processing messages as if the client's infrastructure were the
1091 original destination of the Internet domain's MX record.
1092
10937.1.2. Multi-tier MTA Processing
1094
1095 A large message-processing infrastructure is often divided into
1096 several processing tiers that can break authentication information
1097 between tiers. For example, a large site may maintain a cluster of
1098 MTAs dedicated to connection handling and enforcement of IP-based
1099 reputation filtering. A secondary cluster of MTAs may be dedicated
1100 and optimized for content-based processing of messages.
1101
1102 Authenticated Received Chains can be used to communicate
1103 authentication assessment between processing tiers.
1104
11057.1.3. Mailing Lists
1106
1107 Mailing lists take delivery of messages and repost them to
1108 subscribers. A full description of authentication-related mailing
1109 list issues can be found in [RFC7960], Section 3.2.3.
1110
1111 Mailing list services can implement ARC to convey the authentication
1112 assessment of posted messages sent to the list's subscriber base.
1113 The ADMDs of the mailing list subscribers can then use the
1114 Authenticated Received Chain to determine the authentication
1115 assessment of the original message before mailing list handling.
1116
1117
1118
1119
1120
1121
1122Andersen, et al. Experimental [Page 20]
1123
1124RFC 8617 The ARC Protocol July 2019
1125
1126
11277.2. Inform Message Disposition Decisions
1128
1129 Intermediaries often break authentication through content
1130 modification, interfere with path-based authentication (such as SPF),
1131 and strip authentication results (if an MTA removes Authentication-
1132 Results header fields).
1133
1134 Authenticated Received Chains allow ARC Validators to:
1135
1136 1. identify ARC-enabled ADMDs that break authentication while
1137 processing messages and
1138
1139 2. gain extended visibility into the authentication-preserving
1140 abilities of ADMDs that relay messages into ARC-enabled ADMDs.
1141
1142 Through the collection of ARC-related data, an ADMD can identify
1143 handling paths that have broken authentication.
1144
1145 An Authenticated Received Chain allows an Internet Mail Handler to
1146 potentially base decisions of message disposition on authentication
1147 assessments provided by different ADMDs.
1148
11497.2.1. DMARC Local Policy Overrides
1150
1151 DMARC introduces a policy model where Domain Owners can request email
1152 receivers to reject or quarantine messages that fail DMARC alignment.
1153 Interoperability issues between DMARC and indirect email flows are
1154 documented in [RFC7960].
1155
1156 Authenticated Received Chains allow DMARC processors to consider
1157 authentication assessments provided by other ADMDs. As a matter of
1158 local policy, a DMARC processor MAY choose to accept the
1159 authentication assessments provided by an Authenticated Received
1160 Chain when determining if a message is DMARC compliant.
1161
1162 When an Authenticated Received Chain is used to determine message
1163 disposition, the DMARC processor can communicate this local policy
1164 decision to Domain Owners as described in Section 7.2.2.
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178Andersen, et al. Experimental [Page 21]
1179
1180RFC 8617 The ARC Protocol July 2019
1181
1182
11837.2.2. DMARC Reporting
1184
1185 DMARC-enabled receivers indicate when ARC validation influences
1186 DMARC-related local policy decisions. When an ARC-enabled handler
1187 generates a DMARC report, it MAY indicate the influence of ARC on
1188 their local policy decision(s) by adding a reason of "local_policy"
1189 with a comment string (per [RFC7489], Appendix C) containing a list
1190 of data discovered during ARC validation, which at a minimum
1191 includes:
1192
1193 o the Chain Validation Status,
1194
1195 o the domain and selector for each AS, and
1196
1197 o the originating IP address from the first ARC Set.
1198
1199 EXAMPLE:
1200
1201 <policy_evaluated>
1202 <disposition>none</disposition>
1203 <dkim>fail</dkim>
1204 <spf>fail</spf>
1205 <reason>
1206 <type>local_policy</type>
1207 <comment>arc=pass as[2].d=d2.example as[2].s=s2
1208 as[1].d=d1.example as[1].s=s3
1209 remote-ip[1]=2001:DB8::1A</comment>
1210 </reason>
1211 </policy_evaluated>
1212
1213 In the example DMARC XML reporting fragment above, data relating to
1214 specific validated ARC Sets are enumerated using array syntax (e.g.,
1215 "as[2]" means an AS header field with an instance value of 2).
1216 d2.example is the sealing domain for ARC Set #2 (i=2), and d1.example
1217 is the sealing domain for ARC Set #1 (i=1).
1218
1219 Depending on the reporting practices of intermediate message
1220 handlers, Domain Owners may receive multiple DMARC reports for a
1221 single message. Receivers of DMARC reports should be aware of this
1222 behavior and make the necessary accommodations.
1223
12248. Privacy Considerations
1225
1226 The Authenticated Received Chain provides a verifiable record of the
1227 handlers for a message. This record may include personally
1228 identifiable information such as an IP address(es) and domain names.
1229 Such information is also included in existing non-ARC-related header
1230 fields such as the "Received" header fields.
1231
1232
1233
1234Andersen, et al. Experimental [Page 22]
1235
1236RFC 8617 The ARC Protocol July 2019
1237
1238
12399. Security Considerations
1240
1241 The Security Considerations of [RFC6376] and [RFC8601] apply directly
1242 to this specification.
1243
1244 As with other domain-based authentication technologies (such as SPF,
1245 DKIM, and DMARC), ARC makes no claims about the semantic content of
1246 messages. A received message with a validated ARC Chain provides
1247 evidence (at instance N) that:
1248
1249 1. the sealing domain (ARC-Seal[N] d=) emitted the message with this
1250 body,
1251
1252 2. the authentication assessment reported in the ARC-Authentication-
1253 Results was determined upon receipt of the corresponding message
1254 at the sealing domain, and
1255
1256 3. the preceding ARC Chain (1..N-1) (with the validation status as
1257 reported in the cv field) existed on the message that was
1258 received and assessed.
1259
12609.1. Increased Header Field Size
1261
1262 Inclusion of Authenticated Received Chains into messages may cause
1263 issues for older or constrained MTAs due to increased total header
1264 field size. Large header field blocks, in general, may cause
1265 failures to deliver or other outage scenarios for such MTAs. ARC
1266 itself would not cause problems.
1267
12689.2. DNS Operations
1269
1270 The validation of an Authenticated Received Chain composed of N ARC
1271 Sets can require up to 2*N DNS queries (not including any DNS
1272 redirection mechanisms that can increase the total number of
1273 queries). This leads to two considerations:
1274
1275 1. An attacker can send a message to an ARC participant with a
1276 concocted sequence of ARC Sets bearing the domains of intended
1277 victims, and all of them will be queried by the participant until
1278 a failure is discovered. DNS caching and the difficulty of
1279 forging the signature values should limit the extent of this load
1280 to domains under control of the attacker. Query traffic pattern
1281 analysis may expose information about a downstream validating
1282 ADMD infrastructure.
1283
1284
1285
1286
1287
1288
1289
1290Andersen, et al. Experimental [Page 23]
1291
1292RFC 8617 The ARC Protocol July 2019
1293
1294
1295 2. DKIM only performs one DNS query per signature, while ARC can
1296 introduce many (per chain). Absent caching, slow DNS responses
1297 can cause SMTP timeouts and backlogged delivery queues on
1298 validating systems. This could be exploited as a DoS attack.
1299
13009.3. Message Content Suspicion
1301
1302 Recipients are cautioned to treat messages bearing Authenticated
1303 Received Chains with the same suspicion applied to all other
1304 messages. This includes appropriate content scanning and other
1305 checks for potentially malicious content.
1306
1307 ARC authenticates the identity of some email-handling actors. It
1308 does not make any assessment of their trustworthiness.
1309
1310 Just as passing message authentication is not an indication of
1311 message safety, forwarding that information through the mechanism of
1312 ARC is also not an indication of message safety. Even if all ARC-
1313 enabled ADMDs are trusted, ADMDs may have become compromised, may
1314 miss unsafe content, or may not properly authenticate messages.
1315
13169.4. Message Sealer Suspicion
1317
1318 Recipients are cautioned to treat every Sealer of the ARC Chain with
1319 suspicion. Just as with a validated DKIM signature, responsibility
1320 for message handling is attributed to the sealing domain, but whether
1321 or not that Sealer is a malicious actor is out of scope of the
1322 authentication mechanism. Since ARC aids message delivery in the
1323 event of an authentication failure, ARC Sealers should be treated
1324 with suspicion, so that a malicious actor cannot seal spam or other
1325 fraudulent messages to aid their delivery, too.
1326
13279.5. Replay Attacks
1328
1329 Since ARC inherits heavily from DKIM, it has similar attack vectors.
1330 In particular, the replay attack described in [RFC6376], Section 8.6
1331 is potentially amplified by ARC's chained statuses. In an ARC replay
1332 attack, a malicious actor would take an intact and passing ARC Chain
1333 and resend it to many recipients without making any modifications
1334 that invalidate the latest AMS or AS. The impact to a receiver would
1335 be more DNS lookups and signature evaluations. The scope of this
1336 attack can be limited by caching DNS queries and following the same
1337 signing scope guidance from [RFC6376], Section 5.4.1.
1338
1339
1340
1341
1342
1343
1344
1345
1346Andersen, et al. Experimental [Page 24]
1347
1348RFC 8617 The ARC Protocol July 2019
1349
1350
135110. IANA Considerations
1352
1353 This document defines one new authentication method and several
1354 status codes (Section 10.1), new ptypes and properties
1355 (Section 10.2), three new headers fields (Section 10.3), and a new
1356 enumerated status code (Section 10.4).
1357
135810.1. Update to Email Authentication Result Names Registry
1359
1360 Per this document, IANA has added one authentication method with
1361 three codes to the IANA "Email Authentication Result Names" registry:
1362
1363 o Auth Method: arc
1364 Code: "none", "pass", "fail"
1365 Specification: RFC 8617, Section 4.4
1366 Status: active
1367
136810.2. Update to Email Authentication Methods Registry
1369
1370 Per this document, IANA has added the following to the "Email
1371 Authentication Methods" registry, which is defined in [RFC8601]:
1372
1373 o Method: arc
1374 Definition: RFC 8617, Section 6
1375 ptype: smtp
1376 Property: remote-ip
1377 Value: IP address (v4 or v6) of originating SMTP connection
1378 Status: active
1379 Version: 1
1380
1381 o Method: arc
1382 Definition: RFC 8617, Section 6
1383 ptype: header
1384 Property: oldest-pass
1385 Value: The instance id of the oldest validating AMS or 0 if they
1386 all pass (see Section 5.2)
1387 Status: active
1388 Version: 1
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402Andersen, et al. Experimental [Page 25]
1403
1404RFC 8617 The ARC Protocol July 2019
1405
1406
140710.3. New Header Fields in Permanent Message Header Field Registry
1408
1409 Per this document, IANA has added the following three new header
1410 fields to the "Permanent Message Header Field Names" registry:
1411
1412 o Header field name: ARC-Seal
1413 Applicable protocol: mail
1414 Status: experimental
1415 Author/Change controller: IETF
1416 Specification document(s): RFC 8617
1417 Related information: RFC 6376
1418
1419 o Header field name: ARC-Message-Signature
1420 Applicable protocol: mail
1421 Status: experimental
1422 Author/Change controller: IETF
1423 Specification document(s): RFC 8617
1424 Related information: RFC 6376
1425
1426 o Header field name: ARC-Authentication-Results
1427 Applicable protocol: mail
1428 Status: experimental
1429 Author/Change controller: IETF
1430 Specification document(s): RFC 8617
1431 Related information: RFC 8601
1432
143310.4. New Status Code in Enumerated Status Codes Registry
1434
1435 Per this document, IANA has added the following value to the
1436 "Enumerated Status Codes" registry:
1437
1438 o Code: X.7.29 ../smtp/codes.go:143
1439 Sample Text: ARC validation failure
1440 Associated basic status code: 550
1441 Description: This status code may be returned when a message fails
1442 ARC validation.
1443 Reference: RFC 8617
1444 Submitter: K. Andersen
1445 Change controller: IESG
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458Andersen, et al. Experimental [Page 26]
1459
1460RFC 8617 The ARC Protocol July 2019
1461
1462
146311. Experimental Considerations
1464
1465 The ARC protocol is designed to address common interoperability
1466 issues introduced by intermediate message handlers. Interoperability
1467 issues are described in [RFC6377] and [RFC7960].
1468
1469 As the ARC protocol is implemented by Internet Mail Handlers over
1470 time, the following should be evaluated in order to determine the
1471 success of the protocol in accomplishing the intended benefits.
1472
147311.1. Success Consideration
1474
1475 In an attempt to deliver legitimate messages that users desire, many
1476 receivers use heuristic-based methods to identify messages that
1477 arrive via indirect delivery paths.
1478
1479 ARC will be a success if the presence of Authenticated Received
1480 Chains allows for improved decision making when processing legitimate
1481 messages, specifically resulting in equal or better delivery rates
1482 than achieved through the use of heuristic approaches.
1483
148411.2. Failure Considerations
1485
1486 ARC should function without introducing significant new vectors for
1487 abuse (see Section 9). If unforeseen vectors are enabled by ARC,
1488 this protocol will be a failure. Note that the weaknesses inherent
1489 in the mail protocols ARC is built upon (such as DKIM replay attacks
1490 and other known issues) are not new vectors that can be attributed to
1491 this specification.
1492
149311.3. Open Questions
1494
1495 The following open questions are academic and have no clear answer at
1496 the time this document was published. However, additional
1497 deployments should be able to gather the necessary data to answer
1498 some or all of them.
1499
150011.3.1. Value of the ARC-Seal (AS) Header Field
1501
1502 Data should be collected to show if the AS provides value beyond the
1503 AMS for either making delivery decisions or catching malicious actors
1504 trying to craft or replay malicious chains.
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514Andersen, et al. Experimental [Page 27]
1515
1516RFC 8617 The ARC Protocol July 2019
1517
1518
151911.3.2. Usage and/or Signals from Multiple Selectors and/or Domains in
1520 ARC Sets
1521
1522 Any selectors and/or (sub)domains (under the control of the sealing
1523 ADMD) may be used for ARC header field signatures.
1524
1525 While implementers may choose to use various selectors and/or domains
1526 for ARC Set header fields, no compelling argument for or against such
1527 usage has been made within the working group. As such, we have
1528 chosen to allow maximum freedom for the experimental definition of
1529 this protocol.
1530
1531 Wider deployment experience and higher volumes of traffic may show
1532 whether this is useful.
1533
153411.3.3. DNS Overhead
1535
1536 Longer Authenticated Received Chains will require more queries to
1537 retrieve the keys for validating the chain. While this is not
1538 believed to be a security issue (see Section 9.2), it is unclear how
1539 much overhead will truly be added. This is similar to some of the
1540 initial processing and query load concerns that were debated at the
1541 time of the DKIM specification development.
1542
1543 Data should be collected to better understand usable length and
1544 distribution of lengths found in valid Authenticated Received Chains
1545 along with the DNS impact of processing Authenticated Received
1546 Chains.
1547
1548 An effective operational maximum will have to be developed through
1549 deployment experience in the field.
1550
155111.3.4. What Trace Information Is Valuable?
1552
1553 There are several edge cases where the information in the AAR can
1554 make the difference between message delivery or rejection. For
1555 example, if there is a well-known mailing list that seals with ARC
1556 but doesn't do its own initial DMARC enforcement, an Internet Mail
1557 Handler with this knowledge could make a delivery decision based upon
1558 the authentication information it sees in the corresponding AAR
1559 header field.
1560
1561 Certain trace information in the AAR is useful/necessary in the
1562 construction of DMARC reports.
1563
1564
1565
1566
1567
1568
1569
1570Andersen, et al. Experimental [Page 28]
1571
1572RFC 8617 The ARC Protocol July 2019
1573
1574
1575 Further, certain receivers believe the entire set of trace
1576 information would be valuable to feed into machine learning systems
1577 to identify fraud and/or provide other signals related to message
1578 delivery.
1579
1580 At this point, however, it is unclear what trace information will be
1581 valuable for all receivers, regardless of size.
1582
1583 Data should be collected on what trace information receivers are
1584 using that provides useful signals that affect deliverability and
1585 what portions of the trace data are left untouched or provide no
1586 useful information.
1587
1588 Since many such systems are intentionally proprietary or confidential
1589 to prevent gaming by abusers, it may not be viable to reliably answer
1590 this particular question. The evolving nature of attacks can also
1591 shift the landscape of "useful" information over time.
1592
159312. References
1594
159512.1. Normative References
1596
1597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1598 Requirement Levels", BCP 14, RFC 2119,
1599 DOI 10.17487/RFC2119, March 1997,
1600 <https://www.rfc-editor.org/info/rfc2119>.
1601
1602 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1603 Specifications: ABNF", STD 68, RFC 5234,
1604 DOI 10.17487/RFC5234, January 2008,
1605 <https://www.rfc-editor.org/info/rfc5234>.
1606
1607 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1608 DOI 10.17487/RFC5322, October 2008,
1609 <https://www.rfc-editor.org/info/rfc5322>.
1610
1611 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1612 DOI 10.17487/RFC5598, July 2009,
1613 <https://www.rfc-editor.org/info/rfc5598>.
1614
1615 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1616 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1617 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1618 <https://www.rfc-editor.org/info/rfc6376>.
1619
1620 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
1621 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
1622 September 2011, <https://www.rfc-editor.org/info/rfc6377>.
1623
1624
1625
1626Andersen, et al. Experimental [Page 29]
1627
1628RFC 8617 The ARC Protocol July 2019
1629
1630
1631 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
1632 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
1633 2012, <https://www.rfc-editor.org/info/rfc6532>.
1634
1635 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1636 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1637 DOI 10.17487/RFC7208, April 2014,
1638 <https://www.rfc-editor.org/info/rfc7208>.
1639
1640 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
1641 RFC 7405, DOI 10.17487/RFC7405, December 2014,
1642 <https://www.rfc-editor.org/info/rfc7405>.
1643
1644 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1645 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1646 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1647
1648 [RFC8601] Kucherawy, M., "Message Header Field for Indicating
1649 Message Authentication Status", RFC 8601,
1650 DOI 10.17487/RFC8601, May 2019,
1651 <https://www.rfc-editor.org/info/rfc8601>.
1652
1653 [RFC8616] Levine, J., "Email Authentication for Internationalized
1654 Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019,
1655 <https://www.rfc-editor.org/info/rfc8616>.
1656
165712.2. Informative References
1658
1659 [ARC-MULTI]
1660 Andersen, K., Blank, S., Ed., and J. Levine, Ed., "Using
1661 Multiple Signing Algorithms with the ARC (Authenticated
1662 Received Chain) Protocol", Work in Progress, draft-ietf-
1663 dmarc-arc-multi-03, March 2019.
1664
1665 [ARC-USAGE]
1666 Jones, S., Ed. and K. Andersen, "Recommended Usage of the
1667 Authenticated Received Chain (ARC)", Work in Progress,
1668 draft-ietf-dmarc-arc-usage-07, April 2019.
1669
1670 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1671 Message Authentication, Reporting, and Conformance
1672 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1673 <https://www.rfc-editor.org/info/rfc7489>.
1674
1675
1676
1677
1678
1679
1680
1681
1682Andersen, et al. Experimental [Page 30]
1683
1684RFC 8617 The ARC Protocol July 2019
1685
1686
1687 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
1688 E., Ed., and K. Andersen, Ed., "Interoperability Issues
1689 between Domain-based Message Authentication, Reporting,
1690 and Conformance (DMARC) and Indirect Email Flows",
1691 RFC 7960, DOI 10.17487/RFC7960, September 2016,
1692 <https://www.rfc-editor.org/info/rfc7960>.
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738Andersen, et al. Experimental [Page 31]
1739
1740RFC 8617 The ARC Protocol July 2019
1741
1742
1743Appendix A. Design Requirements
1744
1745 The specification of the ARC framework is driven by the following
1746 high-level goals, security considerations, and practical operational
1747 requirements.
1748
1749A.1. Primary Design Criteria
1750
1751 o Provide a verifiable "chain of custody" for email messages;
1752
1753 o Not require changes for originators of email;
1754
1755 o Support the verification of the ARC header field set by each hop
1756 in the handling chain;
1757
1758 o Work at Internet scale; and
1759
1760 o Provide a trustable mechanism for the communication of
1761 Authentication-Results across trust boundaries.
1762
1763A.2. Out of Scope
1764
1765 ARC is not a trust framework. Users of the ARC header fields are
1766 cautioned against making unsubstantiated conclusions when
1767 encountering a "broken" ARC sequence.
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794Andersen, et al. Experimental [Page 32]
1795
1796RFC 8617 The ARC Protocol July 2019
1797
1798
1799Appendix B. Example Usage
1800
1801 The following message is an example of one that has passed through
1802 several intermediary handlers, some of which have modified the
1803 message and others which have not:
1804
1805Return-Path: <jqd@d1.example>
1806Received: from example.org (example.org [208.69.40.157])
1807 by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207
1808 for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
1809Received: from segv.d1.example (segv.d1.example [72.52.75.15])
1810 by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
1811 for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
1812 (envelope-from jqd@d1.example)
1813Received: from [2001:DB8::1A] (w-x-y-z.dsl.static.isp.example [w.x.y.z])
1814 (authenticated bits=0)
1815 by segv.d1.example with ESMTP id t0FN4a8O084569;
1816 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1817 (envelope-from jqd@d1.example)
1818Received: from mail-ob0-f188.google.example
1819 (mail-ob0-f188.google.example [208.69.40.157]) by
1820 clochette.example.org with ESMTP id d200mr22663000ykb.93.1421363268
1821 for <fmartin@example.org>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
1822ARC-Seal: i=3; a=rsa-sha256; cv=pass; d=clochette.example.org; s=
1823 clochette; t=12345; b=CU87XzXlNlk5X/yW4l73UvPUcP9ivwYWxyBWcVrRs7
1824 +HPx3K05nJhny2fvymbReAmOA9GTH/y+k9kEc59hAKVg==
1825ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=
1826 clochette.example.org; h=message-id:date:from:to:subject; s=
1827 clochette; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZY
1828 LQ=; b=o71vwyLsK+Wm4cOSlirXoRwzEvi0vqIjd/2/GkYFYlSd/GGfKzkAgPqxf
1829 K7ccBMP7Zjb/mpeggswHjEMS8x5NQ==
1830ARC-Authentication-Results: i=3; clochette.example.org; spf=fail
1831 smtp.from=jqd@d1.example; dkim=fail (512-bit key)
1832 header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
1833 ams.2.gmail.example=pass, as.1.lists.example.org=pass,
1834 ams.1.lists.example.org=fail (message has been altered))
1835Authentication-Results: clochette.example.org; spf=fail
1836 smtp.from=jqd@d1.example; dkim=fail (512-bit key)
1837 header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
1838 ams.2.gmail.example=pass, as.1.lists.example.org=pass,
1839 ams.1.lists.example.org=fail (message has been altered))
1840ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=gmail.example; s=20120806; t=
1841 12345; b=Zpukh/kJL4Q7Kv391FKwTepgS56dgHIcdhhJZjsalhqkFIQQAJ4T9BE
1842 8jjLXWpRNuh81yqnT1/jHn086RwezGw==
1843ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
1844 gmail.example; h=message-id:date:from:to:subject; s=20120806; t=
1845 12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=; b=CVoG44
1846 cVZvoSs2mMig2wwqPaJ4OZS5XGMCegWqQs1wvRZJS894tJM0xO1RJLgCPsBOxdA5
1847
1848
1849
1850Andersen, et al. Experimental [Page 33]
1851
1852RFC 8617 The ARC Protocol July 2019
1853
1854
1855 9WSqI9s9DfyKDfWg==
1856ARC-Authentication-Results: i=2; gmail.example; spf=fail
1857 smtp.from=jqd@d1.example; dkim=fail (512-bit key)
1858 header.i=@example.org; dmarc=fail; arc=pass
1859 (as.1.lists.example.org=pass, ams.1.lists.example.org=pass)
1860ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=dk-lists;
1861 t=12345; b=TlCCKzgk3TrAa+G77gYYO8Fxk4q/Ml0biqduZJeOYh6+0zhwQ8u/
1862 lHxLi21pxu347isLSuNtvIagIvAQna9a5A==
1863ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
1864 lists.example.org; h=message-id:date:from:to:subject; s=
1865 dk-lists; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYL
1866 Q=; b=DsoD3n3hiwlrN1ma8IZQFgZx8EDO7Wah3hUjIEsYKuShRKYB4LwGUiKD5Y
1867 yHgcIwGHhSc/4+ewYqHMWDnuFxiQ==
1868ARC-Authentication-Results: i=1; lists.example.org; spf=pass
1869 smtp.mfrom=jqd@d1.example; dkim=pass (512-bit key)
1870 header.i=@d1.example; dmarc=pass
1871DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=d1.example; h=
1872 message-id:date:from:to:subject; s=origin2015; bh=bIxxaeIQvmOBdT
1873 AitYfSNFgzPP4=; b=qKjd5fYibKXWWIcMKCgRYuo1vJ2fD+IAQPjX+uamXIGY2Q
1874 0HjQ+Lq3/yHzG3JHJp6780/nKQPOWt2UDJQrJkEA==
1875Message-ID: <54B84785.1060301@d1.example>
1876Date: Thu, 14 Jan 2015 15:00:01 -0800
1877From: John Q Doe <jqd@d1.example>
1878To: arc@dmarc.example
1879Subject: [List 2] Example 1
1880
1881Hey gang,
1882This is a test message.
1883--J.
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906Andersen, et al. Experimental [Page 34]
1907
1908RFC 8617 The ARC Protocol July 2019
1909
1910
1911Acknowledgments
1912
1913 This document originated with the work of OAR-Dev Group.
1914
1915 The authors thank all of the OAR-Dev and the subsequent DMARC WG for
1916 the ongoing help and thought-provoking discussions from all the
1917 participants, especially J. Trent Adams, Marc Bradshaw, Alex Brotman,
1918 Greg Colburn, Dave Crocker, Tim Draegen, Mark Eissler, Peter
1919 Goldstein, Bron Gondwana, Mike Hammer, Mike Jones, Steve Jones, Scott
1920 Kitterman, Barry Leiba, Franck Martin, John Rae-Grant, Paul Rock,
1921 Gene Shuman, Terry Zink, and Elizabeth Zwicky.
1922
1923 Grateful appreciation is extended to the people who provided feedback
1924 through the arc-discuss mailing list.
1925
1926Authors' Addresses
1927
1928 Kurt Andersen
1929 LinkedIn
1930 1000 West Maude Ave
1931 Sunnyvale, California 94085
1932 United States of America
1933
1934 Email: kurt+ietf@drkurt.com
1935
1936
1937 Brandon Long (editor)
1938 Google
1939
1940 Email: blong@google.com
1941
1942
1943 Seth Blank (editor)
1944 Valimail
1945
1946 Email: seth@valimail.com
1947
1948
1949 Murray Kucherawy (editor)
1950 TDP
1951
1952 Email: superuser@gmail.com
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962Andersen, et al. Experimental [Page 35]
1963
1964