draft-ietf-dmarc-arc-protocol-09.txt   draft-ietf-dmarc-arc-protocol-10.txt 
DMARC Working Group K. Andersen DMARC Working Group K. Andersen
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Standards Track B. Long, Ed. Intended status: Standards Track B. Long, Ed.
Expires: March 10, 2018 Google Expires: June 22, 2018 Google
S. Jones, Ed. S. Jones, Ed.
M. Kucherawy, Ed.
TDP TDP
September 06, 2017 S. Blank, Ed.
ValiMail
December 19, 2017
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-09 draft-ietf-dmarc-arc-protocol-10
Abstract Abstract
The Authenticated Received Chain (ARC) protocol creates a mechanism The Authenticated Received Chain (ARC) protocol creates a mechanism
whereby a series of handlers of an email message can conduct whereby a series of handlers of an email message can conduct
authentication of the email message as it passes among them on the authentication of the email message as it passes among them on the
way to its destination, and record the status of that authentication way to its destination, and record the status of that authentication
at each step along the handling path, for use by the final recipient at each step along the handling path, for use by the final recipient
in making choices about the disposition of the message. Changes in in making choices about the disposition of the message. Changes in
the message that might break DKIM or DMARC can be identified through the message that might break DKIM or DMARC can be identified through
skipping to change at page 1, line 41 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 10, 2018. This Internet-Draft will expire on June 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions and Terminology . . . . . . . . . . . . . . . . . 5 3. Definitions and Terminology . . . . . . . . . . . . . . . . . 6
3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6 3.1. Referenced Definitions . . . . . . . . . . . . . . . . . 6
4. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Elements and Features . . . . . . . . . . . . . . . 7
4.1. Valid Range for Instance Tags . . . . . . . . . . . . . . 7 4.1. Features of the ARC Protocol . . . . . . . . . . . . . . 7
5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Chain of Custody . . . . . . . . . . . . . . . . . . 7
5.1. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 7 4.1.2. Optional Participation . . . . . . . . . . . . . . . 8
5.1.1. Additional Information for the AAR Header . . . . . . 7 4.1.3. Only one ARC Chain (One Chain to Rule Them All) . . . 8
5.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 8 4.1.4. All Failures are Permanent . . . . . . . . . . . . . 8
5.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 8 4.1.5. Benign nature of an ARC Set . . . . . . . . . . . . . 9
5.3.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 9 4.1.6. Key Management . . . . . . . . . . . . . . . . . . . 9
5.3.2. Selected Header Fields . . . . . . . . . . . . . . . 9 4.1.7. Trace Information . . . . . . . . . . . . . . . . . . 9
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 10 5. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 9
7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 9
8. Key Management . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. Valid Range for Instance Tags . . . . . . . . . . . . 10
9. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 12 5.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 10
9.1. Relationship between DKIM-Signature and AMS signing 5.2.1. ptypes and properties for arc-info . . . . . . . . . 11
scopes . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 11
9.2. Assessing Chain Validity Violations . . . . . . . . . . . 12 5.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 12
9.3. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 13 5.4.1. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 12
9.4. Handling DNS Problems While Validating ARC . . . . . . . 13 5.4.2. Implicit Header Fields . . . . . . . . . . . . . . . 13
9.5. Responding to ARC Validity Violations . . . . . . . . . . 13 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 13
10. Recording and Reporting the Results of ARC Evaluation . . . . 13 7. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Information from an ARC Evaluation . . . . . . . . . . . 13 8. Usage of ARC and Chain Validity . . . . . . . . . . . . . . . 16
10.2. Recording (local) ARC Evaluation Results . . . . . . . . 14 8.1. Relationship between DKIM-Signature and AMS signing
10.3. DMARC Reporting of ARC Findings - Interim . . . . . . . 14 scopes . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Supporting Alternate Signing Algorithms . . . . . . . . . . . 15 8.2. Assessing Chain Validity Violations . . . . . . . . . . . 16
11.1. Introductory Period . . . . . . . . . . . . . . . . . . 15 8.3. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 16
11.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 15 8.4. Handling DNS Problems While Validating ARC . . . . . . . 16
11.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 15 8.5. Responding to ARC Validity Violations . . . . . . . . . . 16
11.4. Obsolescence Period . . . . . . . . . . . . . . . . . . 15 9. Recording and Reporting the Results of ARC Evaluation . . . . 17
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 9.1. Information from an ARC Evaluation . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9.2. Recording (local) ARC Evaluation Results . . . . . . . . 17
13.1. Authentication-Results Method Registry Update . . . . . 16 9.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 17
13.2. Definitions of the ARC header fields . . . . . . . . . . 16 10. Supporting Alternate Signing Algorithms . . . . . . . . . . . 18
14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10.1. Introductory Period . . . . . . . . . . . . . . . . . . 18
14.1. Message Content Suspicion . . . . . . . . . . . . . . . 17 10.2. Co-Existence Period . . . . . . . . . . . . . . . . . . 18
10.3. Deprecation Period . . . . . . . . . . . . . . . . . . . 19
15. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 10.4. Obsolescence Period . . . . . . . . . . . . . . . . . . 19
15.1. GMail test reflector and incoming validation . . . . . . 18 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
15.2. AOL test reflector and internal tagging . . . . . . . . 19 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
15.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Authentication-Results Method Registry Update . . . . . 19
15.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 20 12.2. Definitions of the ARC header fields . . . . . . . . . . 19
15.5. Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . . 20 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20
15.6. Copernica/MailerQ web-based validation . . . . . . . . . 21 13.1. Header Size . . . . . . . . . . . . . . . . . . . . . . 20
15.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21
15.8. PERL Mail::Milter::Authentication module . . . . . . . . 22 13.3. Message Content Suspicion . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
16.1. Normative References . . . . . . . . . . . . . . . . . . 22 14.1. GMail test reflector and incoming validation . . . . . . 22
16.2. Informative References . . . . . . . . . . . . . . . . . 24 14.2. AOL test reflector and internal tagging . . . . . . . . 22
16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Appendix A - Design Requirements . . . . . . . . . . 25 14.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 23
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 25 14.5. Mailman 3.1+ patch . . . . . . . . . . . . . . . . . . . 24
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 26 14.6. Copernica/MailerQ web-based validation . . . . . . . . . 24
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 26 14.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 26 14.8. PERL Mail::Milter::Authentication module . . . . . . . . 25
B.1.1. Here's the message as it exits the Origin: . . . . . 26 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.1.2. Message is then received at example.org . . . . . . . 27 15.1. Normative References . . . . . . . . . . . . . . . . . . 26
B.1.3. Example 1: Message received by Recipient . . . . . . 29 15.2. Informative References . . . . . . . . . . . . . . . . . 27
B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 30 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
B.2.1. Here's the message as it exits the Origin: . . . . . 30 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 29
B.2.2. Message is then received at example.org . . . . . . . 31 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 29
B.2.3. Example 2: Message received by Recipient . . . . . . 35 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 29
B.3. Example 3: Mailing list to forwarded mailbox with source 37 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 29
B.3.1. Here's the message as it exits the Origin: . . . . . 37 B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 30
B.3.2. Message is then received at example.org . . . . . . . 38 B.1.1. Here's the message as it exits the Origin: . . . . . 30
B.3.3. Example 3: Message received by Recipient . . . . . . 43 B.1.2. Message is then received at example.org . . . . . . . 30
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 45 B.1.3. Example 1: Message received by Recipient . . . . . . 32
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 46 B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 B.2.1. Here's the message as it exits the Origin: . . . . . 33
B.2.2. Message is then received at example.org . . . . . . . 34
B.2.3. Example 2: Message received by Recipient . . . . . . 38
B.3. Example 3: Mailing list to forwarded mailbox with source 40
B.3.1. Here's the message as it exits the Origin: . . . . . 40
B.3.2. Message is then received at example.org . . . . . . . 41
B.3.3. Example 3: Message received by Recipient . . . . . . 46
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 48
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
Modern email authentication techniques such as the Sender Policy Modern email authentication techniques such as the Sender Policy
Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
[RFC6376] have become common. [RFC6376] have become common.
However, their end-to-end utility is limited by the effects of However, their end-to-end utility is limited by the effects of
intermediaries along the transmission path, which either are not intermediaries along the transmission path, which either are not
listed (for SPF) or which break digital signatures (for DKIM). These listed (for SPF) or which break digital signatures (for DKIM). These
issues are described in substantial detail in those protocols' issues are described in substantial detail in those protocols'
skipping to change at page 5, line 14 skipping to change at page 5, line 30
This protocol accomplishes each of these by adding a new header field This protocol accomplishes each of these by adding a new header field
to the message for each of these pieces of information, as follows: to the message for each of these pieces of information, as follows:
o ARC-Authentication-Results (referred to below as "AAR"): virtually o ARC-Authentication-Results (referred to below as "AAR"): virtually
identical in syntax to an Authentication-Results field [RFC7601], identical in syntax to an Authentication-Results field [RFC7601],
this field records the results of all message authentication this field records the results of all message authentication
checks done by the recording ADMD at the time the message arrived. checks done by the recording ADMD at the time the message arrived.
Additional information is placed in this field compared to a Additional information is placed in this field compared to a
standard Authentication-Results field in order to support a more standard Authentication-Results field in order to support a more
complete DMARC report (see Section 5.1); complete DMARC report (see Section 5.2);
o ARC-Message-Signature (referred to below as "AMS"): virtually o ARC-Message-Signature (referred to below as "AMS"): virtually
identical in syntax to DKIM-Signature, this field contains the identical in syntax to DKIM-Signature, this field contains the
signature about the message header and body as they existed at the signature about the message header and body as they existed at the
time of handling by the ADMD adding it; and time of handling by the ADMD adding it; and
o ARC-Seal (referred to below as "AS"): highly similar in structure o ARC-Seal (referred to below as "AS"): highly similar in structure
and format to a DKIM-Signature, this field applies a digital and format to a DKIM-Signature, this field applies a digital
signature that protects the integrity of all three of these new signature that protects the integrity of all three of these new
fields when they are added by an ADMD, plus all instances of these fields when they are added by an ADMD, plus all instances of these
fields added by prior ADMDs. fields added by prior ADMDs.
A distinguishing feature of all of these is that an ARC participant A distinguishing feature of all of these is that an ARC participant
always adds all of them before relaying a message to the next always adds all of them before relaying a message to the next
handling agent en route to its destination. Moreover, as described handling agent en route to its destination. Moreover, as described
in Section 4, they each have an "instance" number that increases with in Section 5.1, they each have an "instance" number that increases
each ADMD in the handling chain so that their original order can be with each ADMD in the handling chain so that their original order can
preserved and the three related header fields can be processed as a be preserved and the three related header fields can be processed as
group. a group.
3. Definitions and Terminology 3. Definitions and Terminology
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Because many of the core concepts and definitions are found in Because many of the core concepts and definitions are found in
skipping to change at page 6, line 34 skipping to change at page 7, line 5
o MDA - [RFC5598], Section 4.3.3 o MDA - [RFC5598], Section 4.3.3
The three header fields that are part of this specification borrow The three header fields that are part of this specification borrow
heavily from existing specifications. Rather than repeating all of heavily from existing specifications. Rather than repeating all of
the formal definitions that are being reused in ARC, this document the formal definitions that are being reused in ARC, this document
only describes and specifies changes in syntax and semantics. only describes and specifies changes in syntax and semantics.
Language, syntax, and other details are imported from DKIM [RFC6376]. Language, syntax, and other details are imported from DKIM [RFC6376].
Specific references can be found below. Specific references can be found below.
4. Instance ('i=') Tag 4. Protocol Elements and Features
As with other domain authentication technologies (such as SPF, DKIM,
and DMARC), ARC makes no claims about the contents of the email
message it has sealed. However, for a valid and passing ARC chain, a
Final Receiver is able to ascertain:
o all (participating) domains that claim responsibility for handling
(and possibly) modifying the email message in transit;
o trace information, including:
* the [RFC7601] authentication results each participating ADMD
saw; and
* additional data needed to compile a DMARC report for the
sending domain.
Given this information, a Final Receiver is able to make a more-
informed local policy decision regarding message delivery to the end
user in spite of a DMARC failure.
Every participant in an ARC chain, except for the originating sender
and Final Receiver, is both an ARC Validator (when receiving) and
then an ARC Sealer (when sending a message onward). The validated
chain status as determined at message receipt must be passed to the
sealer function in order for sealing to occur properly; how this is
done is considered ADMD-specific and an implementation detail.
_INFORMATIONAL_: It is important to understand that validating and
then immediately sealing a message leaves no room for message
modification, and many early implementations of ARC did not initially
work because both operations were performed in a single pass over the
message.
4.1. Features of the ARC Protocol
The following protocol features are functional parts and design
decisions related the protocol that are not specific to either
Validators or Sealers, but ensure the ARC chain conveys this
information to a Final Receiver.
4.1.1. Chain of Custody
At a high level, an ARC chain represents a chain of custody of
authentication and other trace information (AAR) related to a
message, signed by each handler of the message. Each link in the
chain (AMS) is designed to be brittle, insofar as it survives only
until the next modification of the message. However, the sequence of
intermediaries in the handling chain (AS) is designed to remain
intact over the entirety of the chain.
The ARC chain can be conceptualized through an analogy with the chain
of custody for legal evidence. The material evidence itself is
sealed within an tamper-proof bag (AMS) each time. When handed to a
new party, that party both vouches for the state of the received
evidence container (AAR) and signs for the evidence on a chain of
custody report form (AS). As with all analogies, this one should not
be taken to interpretive extremes, but primarily used as a conceptual
framework.
An ARC chain that is valid and passing has the attributes listed
above in Section 4.
Recipients of an ARC chain that is invalid or does not pass SHOULD
NOT draw negative conclusions without a good understanding of the
wider handling context. Until ARC usage is widespread,
intermediaries will continue to modify messages without ARC seals.
As with a failing DKIM signature ([RFC6376] Section-6.3), a failing
ARC chain SHOULD be treated the same as a message with no ARC chain.
[[ NOTE TO WORKING GROUP: This paragraph probably is better placed in
Verifier actions. ]]
4.1.2. Optional Participation
Validating an existing chain and then adding your own ARC set to a
message allows you to claim responsibility for hanndling the message
and modifications, if any, done by your ADMD to benefit message
delivery downstream. However, no ADMD is obligated to perform these
actions.
4.1.3. Only one ARC Chain (One Chain to Rule Them All)
A message can have only one ARC chain on it at a time. Once broken,
the chain cannot be restarted, as the chain of custody is no longer
valid and responsibility for the message has been lost.
4.1.4. All Failures are Permanent
Because ARC chains are transmitted across multiple intermediaries,
all errors, even temporary ones, become unrecoverable and are
considered permanent.
Any error validating or sealing a chain, for whatever reason, MUST
result in a "cv=fail" verdict.
4.1.5. Benign nature of an ARC Set
Even when an ARC chain is valid and passes, its value is limited to
very specific cases. An ARC chain is specifically designed to
provide value to a Final Receiver evaluating message delivery in the
context of a DMARC failure. An ARC chain in general, and each ARC
set in particular, provide additional information, and otherwise is
benign. Specifically:
o properly adding an ARC set to a message does not damage or
invalidate an existing chain, and
o validating a message exposes no new threat vectors (see
Section 13).
_INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting
and/or modifying a message, it may elect to seal all inbound mail.
For complex or nested ADMD relationships such as found in some hosted
mail solutions, this "inbound seal" can be used to facilitate
traversal of internal boundaries as well as properly conveying
incoming state to any egress MTAs that may need to assert a seal upon
exit from the ADMD. Since these internal relationships are highly
implementation dependent, this protocol definition can not usefully
explore such usage except to note that it is intentionally allowed
within the scope of this specification.
4.1.6. Key Management
The public keys for ARC header fields follow the same requirements,
syntax and semantics as those for DKIM signatures, described in
Section 3.6 of [RFC6376]. ARC places no requirements on the
selectors and/or domains used for the ARC header field signatures.
4.1.7. Trace Information
ARC includes trace information encoded in the AAR. While section
Section 5.2 defines what information must be provided, sealing ADMDs
may provide additional information, and validating receivers may use
or ignore this trace information as they wish.
5. The ARC Header Fields
5.1. Instance ('i=') Tag
The header fields comprising a single ARC set are identified by the The header fields comprising a single ARC set are identified by the
presence of a string in the value portion of the header field that presence of a string in the value portion of the header field that
complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376]. complies with the "tag-spec" ABNF found in Section 3.2 of [RFC6376].
The tag-name is "i" and the value is the text representation of a The tag-name is "i" and the value is the text representation of a
positive integer, indicating the position in the ARC sequence this positive integer, indicating the position in the ARC sequence this
set occupies, where the first ARC set is numbered 1. In ABNF terms: set occupies, where the first ARC set is numbered 1. In ABNF terms:
instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";" instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";"
position = 1*DIGIT position = 1*2DIGIT ; 1 - 50
Valid ARC sets must have exactly one instance of each header field Valid ARC sets must have exactly one instance of each header field
for a given position value. (Note that when multiple algorithms are for a given position value. (Note that when multiple algorithms are
supported, there is some nuance to this statement - see Section 11.) supported, there is some nuance to this statement - see Section 10.)
Because the AMS and AS header field values are made up of tag-spec Because the AMS and AS header field values are made up of tag-spec
constructs, the i= tag may be found anywhere within the header field constructs, the i= tag may be found anywhere within the header field
value, but is represented throughout this spec in the initial value, but is represented throughout this spec in the initial
position for convenience. Implementers are encouraged to place the position for convenience. Implementers are encouraged to place the
i= tag at the beginning of the field value to facilitate human i= tag at the beginning of the field value to facilitate human
inspection of the headers. inspection of the headers.
4.1. Valid Range for Instance Tags 5.1.1. Valid Range for Instance Tags
The 'i' tag value can range from 1-1024 (inclusive). The 'i' tag value can range from 1-50 (inclusive).
ARC implementations MUST support at least ten (10) ARC sets. ARC implementations MUST support at least ten (10) ARC sets.
An effective operational maximum will have to be developed through An effective operational maximum will have to be developed through
deployment experience in the field and will be documented within deployment experience in the field and will be documented within
[ARC-USAGE] once determined. [ARC-USAGE] once determined.
ARC chains with more than the defined operational maximum count MAY ARC chains with more than the defined operational maximum count MUST
be marked with "cv=fail". be marked with "cv=fail".
5. The ARC Header Fields 5.2. ARC-Authentication-Results (AAR)
5.1. ARC-Authentication-Results (AAR)
The ARC-Authentication-Results header field is syntactically and The ARC-Authentication-Results header field is syntactically and
semantically identical to an Authentication-Results header field semantically identical to an Authentication-Results header field
(defined in Section 2.2 of [RFC7601] (A-R)), except for one mandatory (defined in Section 2.2 of [RFC7601] (A-R)), except that several
addition and several optional data fields. These deviations are: optional data fields SHOULD be added. ([[ NOTE: these optional data
fields are being proposed as amendments to [RFC7601] through a "bis"
o There is an "i" tag, as described in Section 4; and process. Depending on the sequencing for this specification and said
"7601bis" work, it may be possible to drop the noted sections from
o Two (or more) additional pieces of information MAY be added (see this specification. ]]) The first element ("Authentication-Results:")
Section 5.1.1). in authres-header is replaced with arc-authres-prefix as follows:
The instance identifier MUST be separated from the rest of the arc-authres-header-prefix = "ARC-Authentication-Results:" [CFWS] arc-info
Authentication-Results value contents with a semi-colon (';', 0x3b). arc-info = instance *([CFWS] propspec) [CFWS] ";"
The purpose of this header field is to incorporate into the record The purpose of this header field is to transmit the results of any
the success or failure of any authentication done on the message authentication done on the message upstream to participating ADMDs
upstream of the participating ADMD that is validating and continuing validating and continuing the chain.
the authentication chain.
The AAR MUST contain all A-R results from within the participating The AAR MUST contain all A-R results from within the participating
ADMD, regardless of how many A-R headers are on the message. ADMD, regardless of how many A-R headers are on the message.
5.1.1. Additional Information for the AAR Header 5.2.1. ptypes and properties for arc-info
An ARC signer generates this field in the same way that a [[ NOTE: This section is being proposed as an amendment to [RFC7601]
conventional A-R field would be generated. Because the AAR is through a "bis" process. Depending on the sequencing for this
designed for machine-based consumption over the course of a message's specification and said "7601bis" work, it may be possible to this
transit through a series of mediators and to facilitate section from this specification. ]]
troubleshooting of problematic sources by sending organizations,
three additional fields of data SHOULD be added to the normal A-R
content, dependent on the presence of DKIM-Signature and/or ARC
set(s) and if available to the ADMD which is recording the A-R:
o smtp.client_id - The connecting client IP address from which the Certain information pertinent to ascertaining message disposition can
message was received; be lost in transit when messages are handled by intermediaries. For
example, failing DKIM signatures are sometimes removed by MTAs, and
most DKIM signatures on messages modified by intermediaries will
fail.
o header.ds - The domain/selector pair for each dkim signature on The AAR, through these ptype-properties stamped in arc-info, provide
the message (header.ds=example.com,selector) a mechanism for this information to survive transit.
o arc.closest_fail - The hop number of the most recent AMS that The ptypes and properties defined in this section SHOULD be stamped
fails to validate, or 0 if all hops pass. in the AAR:
5.2. ARC-Message-Signature (AMS) o smtp.client-ip - The connecting client IP address from which the
message is received;
o header.ds - The domain/selector pair for each DKIM signature on
the message (header.ds=example.com,selector). Note that this is a
concatenation of the header.d and header.s field values from [[
TODO: reference DKIM A-R method spec ]] separated by the comma
character (0x2c). These values are joined into a single arc-info
field value in order to avoid indexing and correlation ambiguity
between the possible multiple DKIM signatures which may be found
on any given message;
o arc.closest-fail - The hop number of the most recent AS that fails
to validate, or 0 if all hops pass.
5.3. ARC-Message-Signature (AMS)
The ARC-Message-Signature header field is syntactically and The ARC-Message-Signature header field is syntactically and
semantically identical to a DKIM-Signature header field [RFC6376], semantically identical to a DKIM-Signature header field [RFC6376],
with the following exceptions: with the following exceptions:
o There is an "i" tag, as described in Section 4. o There is an "i" tag, as described in Section 5.1.
o There is no "v" tag. o There is no "v" tag.
ARC-Seal header fields MUST NOT be included in the content covered by ARC-Seal header fields MUST NOT be included in the content covered by
the signature in this header field. the signature in this header field.
The AMS SHOULD include any DKIM-Signature header fields already The AMS SHOULD include any DKIM-Signature header fields already
present on the message in the header fields covered by this present on the message in the header fields covered by this
signature. signature.
The AMS header field MAY include (sign) the AAR header field(s). The AMS header field MAY include (sign) the AAR header field(s).
Authentication-Results header fields SHOULD NOT be included since Authentication-Results header fields SHOULD NOT be included since
they are likely to be deleted by downstream ADMDs (per Section XXX of they are likely to be deleted by downstream ADMDs (per Section XXX of
[RFC7601]), thereby breaking the AMS signature. [RFC7601]), thereby breaking the AMS signature.
As with a DKIM-Signature, the purpose of this header field is to As with a DKIM-Signature, the purpose of this header field is to
allow the ADMD generating it to take some responsibility for handling allow the ADMD generating it to take some responsibility for handling
this message as it progresses toward delivery. this message as it progresses toward delivery.
5.3. ARC-Seal (AS) 5.4. ARC-Seal (AS)
The ARC-Seal header field is syntactically and semantically similar The ARC-Seal header field is syntactically and semantically similar
to a DKIM-Signature field, with the following exceptions: to a DKIM-Signature field, with the following exceptions:
o There is an "i" tag, as described in Section 4. o There is an "i" tag, as described in Section 5.1.
o The ARC-Seal covers none of the body content of the message. It o The ARC-Seal covers none of the body content of the message. It
only covers specific header fields. (See below: Section 5.3.2.) only covers specific header fields. (See below: Section 5.4.2.)
As a result, no body canonicalization is done. Further, only As a result, no body canonicalization is done. Further, only
"relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is "relaxed" header canonicalization (Section 3.4.2 of [RFC6376]) is
used. used.
o The only supported tags are "i" (Section 4 supercedes the o The only supported tags are "i" (Section 5.1 supercedes the
[RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5 [RFC6376] definition), and "a", "b", "d, "s", "t". The latter 5
tag definitions are copied from Section 3.5 of [RFC6376]. tag definitions are copied from Section 3.5 of [RFC6376].
o An additional tag, "cv" is defined. (See below: Section 5.3.1) o An additional tag, "cv" is defined. (See below: Section 5.4.1)
5.3.1. The 'cv' Tag 5.4.1. The 'cv' Tag
A new tag "cv" (chain validation) indicates the the outcome of A new tag "cv" (chain validation) indicates the the outcome of
evaluating the existing ARC chain upon arrival at the ADMD that is evaluating the existing ARC chain upon arrival at the ADMD that is
adding this header field. It accepts one of three possible values: adding this header field. It accepts one of three possible values:
o none: There was no chain on the message when it arrived for o none: There was no chain on the message when it arrived for
validation; typically occurs when the message arrives at a Message validation; typically occurs when the message arrives at a Message
Transfer Agent (MTA) from a Message Submission Agent (MSA) or when Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
any upstream MTAs may not be participating in ARC handling; any upstream MTAs may not be participating in ARC handling;
skipping to change at page 9, line 29 skipping to change at page 13, line 4
A new tag "cv" (chain validation) indicates the the outcome of A new tag "cv" (chain validation) indicates the the outcome of
evaluating the existing ARC chain upon arrival at the ADMD that is evaluating the existing ARC chain upon arrival at the ADMD that is
adding this header field. It accepts one of three possible values: adding this header field. It accepts one of three possible values:
o none: There was no chain on the message when it arrived for o none: There was no chain on the message when it arrived for
validation; typically occurs when the message arrives at a Message validation; typically occurs when the message arrives at a Message
Transfer Agent (MTA) from a Message Submission Agent (MSA) or when Transfer Agent (MTA) from a Message Submission Agent (MSA) or when
any upstream MTAs may not be participating in ARC handling; any upstream MTAs may not be participating in ARC handling;
o fail: The message has a chain whose validation failed; o fail: The message has a chain whose validation failed;
o pass: The message has a chain whose validation succeeded. o pass: The message has a chain whose validation succeeded.
In ABNF terms: In ABNF terms:
seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass") seal-cv-tag = %x63.76 [FWS] "=" [FWS] ("none" / "fail" / "pass")
5.3.2. Selected Header Fields 5.4.2. Implicit Header Fields
[[ Note: reword sentence 1 per Dave's comments ]]
The ARC-Seal signature is a signature of the hash of the The ARC-Seal signs a canonicalized form of the ARC set header values.
concatenation of the canonicalized form of the ARC sets present on The ARC set header values are compiled in increasing instance order,
the message at the time of sealing, in increasing instance order, starting at 1, and inclue the set being added at the time of sealing
starting at 1, including the one being added at the time of sealing
the message. the message.
Within a set, the header fields are listed in the following order: Within a set, the header fields are listed in the following order:
1. ARC-Authentication-Results 1. ARC-Authentication-Results
2. ARC-Message-Signature 2. ARC-Message-Signature
3. ARC-Seal 3. ARC-Seal
Where the ARC-Seal is the one being generated, it is input to the Where the ARC-Seal is the one being generated, it is input to the
hash function in its final form except with an empty "b=" value, in hash function in its final form except with an empty "b=" value, in
the same manner by which a DKIM-Signature signs itself. the same manner by which a DKIM-Signature signs itself.
Note that the signing scope for the ARC-Seal is modified in the Note that the signing scope for the ARC-Seal is modified in the
situation where a chain has failed validation (see Section 9.3). situation where a chain has failed validation (see Section 8.3).
6. Verifier Actions 6. Verifier Actions
The verifier takes the following steps to determine the current state The verifier takes the following steps to determine the current state
of the ARC chain on the message. Canonicalization, hash functions, of the ARC chain on the message. Canonicalization, hash functions,
and signature validation methods are imported from Section 5 of and signature validation methods are imported from Section 5 of
[RFC6376]. [RFC6376].
[[ Note: need markdown flag to have subordinate numbering distinction [[ Note: need markdown flag to have subordinate numbering distinction
]] ]]
skipping to change at page 11, line 9 skipping to change at page 14, line 28
2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv 2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv
== "none" && i != 1)) then the chain state is "fail" and the == "none" && i != 1)) then the chain state is "fail" and the
algorithm stops here (note that the ordering of the logic is algorithm stops here (note that the ordering of the logic is
structured for short-circuit evaluation). structured for short-circuit evaluation).
3. Initialize a hash function corresponding to the "a" tag of 3. Initialize a hash function corresponding to the "a" tag of
the ARC-Seal. the ARC-Seal.
4. Compute the canonicalized form of the ARC header fields, in 4. Compute the canonicalized form of the ARC header fields, in
the order described in Section 5.3.2, using the "relaxed" the order described in Section 5.4.2, using the "relaxed"
header canonicalization defined in Section 3.4.2 of header canonicalization defined in Section 3.4.2 of
[RFC6376]. Pass the canonicalized result to the hash [RFC6376]. Pass the canonicalized result to the hash
function. function.
5. Retrieve the final digest from the hash function. 5. Retrieve the final digest from the hash function.
6. Retrieve the public key identified by the "s" and "d" tags in 6. Retrieve the public key identified by the "s" and "d" tags in
the ARC-Seal, as described in Section 8. the ARC-Seal, as described in Section 4.1.6.
7. Determine whether the signature portion ("b" tag) of the ARC- 7. Determine whether the signature portion ("b" tag) of the ARC-
Seal and the digest computed above are valid according to the Seal and the digest computed above are valid according to the
public key. (See also Section Section 9.4 for failure case public key. (See also Section Section 8.4 for failure case
handling) handling)
8. If the signature is not valid, the chain state is "fail" and 8. If the signature is not valid, the chain state is "fail" and
the algorithm stops here. the algorithm stops here.
5. If all seals pass validation, then the chain state is "pass", and 5. If all seals pass validation, then the chain state is "pass", and
the algorithm is complete. the algorithm is complete.
[[ Note from Dave: possibly delete the following paragraph as it is [[ Note from Dave: possibly delete the following paragraph as it is
more usage/procedural than specification guidance. KA: It was added more usage/procedural than specification guidance.
to clarify the separation of the verification and signing steps as
some of the initial implementations failed to realize that they were KA: It was added to clarify the separation of the verification and
not necessarily done in one fell swoop. ]] signing steps as some of the initial implementations failed to
realize that they were not necessarily done in one fell swoop.
KA (v-10): With the addition of the {protocol-elements} section, does
the WG think that this can be reasonably removed from this location?
]]
The verifier should save the cv state for subsequent use by any The verifier should save the cv state for subsequent use by any
sealing which may be done later (potentially after message sealing which may be done later (potentially after message
modification) within the same trust boundary. The cv state may be modification) within the same trust boundary. The cv state may be
recorded by sealing at the time of verification in an initial ARC set recorded by sealing at the time of verification in an initial ARC set
(for the ADMD) or may be recorded out of band depending on the (for the ADMD) or may be recorded out of band depending on the
architecture of the ADMD. architecture of the ADMD.
7. Signer Actions 7. Signer Actions
skipping to change at page 12, line 20 skipping to change at page 15, line 46
1. If an ARC chain exists on the message, then set "N" equal to 1. If an ARC chain exists on the message, then set "N" equal to
the highest instance number found on the chain (i=); the highest instance number found on the chain (i=);
otherwise set "N" equal to zero for the following steps. otherwise set "N" equal to zero for the following steps.
2. Generate and attach to the message an ARC-Authentication- 2. Generate and attach to the message an ARC-Authentication-
Results header field using instance number N+1 and the same Results header field using instance number N+1 and the same
content from the previous step. content from the previous step.
3. Generate and attach to the message an ARC-Message-Signature 3. Generate and attach to the message an ARC-Message-Signature
header field as defined in Section 5.2 above, using instance header field as defined in Section 5.3 above, using instance
number N+1. number N+1.
4. Generate and attach to the message an ARC-Seal header field 4. Generate and attach to the message an ARC-Seal header field
using the general algorithm described in Section 5.3 above, using the general algorithm described in Section 5.4 above,
the chain validation status as determined in Section 6, and the chain validation status as determined in Section 6, and
instance number N+1. instance number N+1.
8. Key Management 8. Usage of ARC and Chain Validity
The public keys for ARC header fields follow the same requirements,
syntax and semantics as those for DKIM signatures, described in
Section 3.6 of [RFC6376]. For operational convenience, signers MAY
choose to use selectors and/or domains for the ARC header field
signatures that are distinct from those used in DKIM signing.
9. Usage of ARC and Chain Validity
9.1. Relationship between DKIM-Signature and AMS signing scopes 8.1. Relationship between DKIM-Signature and AMS signing scopes
DKIM-Signatures SHOULD never sign any ARC header fields. DKIM-Signatures SHOULD never sign any ARC header fields.
[[ KA: Response to Dave's concern: If DKIM covers ARC and ARC covers [[ KA: Response to Dave's concern: If DKIM covers ARC and ARC covers
DKIM, which comes first? The chicken or the egg? I'm open to DKIM, which comes first? The chicken or the egg? I'm open to
alternate ways to phrase this without opening the "modifying the DKIM alternate ways to phrase this without opening the "modifying the DKIM
spec" can of worms. ]] spec" can of worms. ]]
9.2. Assessing Chain Validity Violations 8.2. Assessing Chain Validity Violations
Email transit can produce broken signatures for a wide variety of Email transit can produce broken signatures for a wide variety of
benign reasons. This includes possibly breaking one or more ARC benign reasons. This includes possibly breaking one or more ARC
signatures. Therefore, receivers need to be wary of ascribing motive signatures. Therefore, receivers need to be wary of ascribing motive
to such breakage although patterns of common behaviour may provide to such breakage although patterns of common behaviour may provide
some basis for adjusting local policy decisions. some basis for adjusting local policy decisions.
ARC does not attempt to protect an entire message. There are various ARC does not attempt to protect an entire message. There are various
ways that a message can still be problematic, in spite of having a ways that a message can still be problematic, in spite of having a
valid ARC chain. Consequently, all normal, content-based analysis valid ARC chain. Consequently, all normal, content-based analysis
SHOULD still be performed on any message having a valid chain of ARC SHOULD still be performed on any message having a valid chain of ARC
header sets. header sets.
9.3. Marking and Sealing "cv=fail" (Invalid) Chains 8.3. Marking and Sealing "cv=fail" (Invalid) Chains
The header fields signed by the AS header field b= value in the case The header fields signed by the AS header field b= value in the case
of a chain failure MUST be only the matching 'i=' instance headers of a chain failure MUST be only the matching 'i=' instance headers
created by the MTA which detected the malformed chain, as if this created by the MTA which detected the malformed chain, as if this
newest ARC set was the only set present. newest ARC set was the only set present.
9.4. Handling DNS Problems While Validating ARC 8.4. Handling DNS Problems While Validating ARC
DNS-based failures to verify a chain are treated no differently than DNS-based failures to verify a chain are treated no differently than
any other ARC violation. They result in a "cv=fail" verdict. any other ARC violation. They result in a "cv=fail" verdict.
9.5. Responding to ARC Validity Violations 8.5. Responding to ARC Validity Violations
If a receiver determines that the ARC chain has failed, the receiver If a receiver determines that the ARC chain has failed, the receiver
MAY signal the breakage through the extended SMTP response code 5.7.7 MAY signal the breakage through the extended SMTP response code 5.7.7
[RFC3463] "message integrity failure" [ENHANCED-STATUS] and [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
corresponding SMTP response code. corresponding SMTP response code.
10. Recording and Reporting the Results of ARC Evaluation 9. Recording and Reporting the Results of ARC Evaluation
The evaluation of an ARC chain provides information which will be The evaluation of an ARC chain provides information which will be
useful to both the receiver (or intermediary) and to the initial useful to both the receiver (or intermediary) and to the initial
sender of the message. This information should be preserved and sender of the message. This information should be preserved and
reported as follows. reported as follows.
10.1. Information from an ARC Evaluation 9.1. Information from an ARC Evaluation
The evaluation of an ARC chain produces a list of domain names for The evaluation of an ARC chain produces a list of domain names for
participating intermediaries which handled the message, to wit: participating intermediaries which handled the message, to wit:
o A list of the "d=" domains found in the validated ARC-Seal header o A list of the "d=" domains found in the validated ARC-Seal header
fields fields
o The "d=" domain found in the most recent (highest instance number) o The "d=" domain found in the most recent (highest instance number)
AMS header field (since that is the only one necessarily AMS header field (since that is the only one necessarily
validated) validated)
In the case of a failed chain, only the terminal ARC set is covered In the case of a failed chain, only the terminal ARC set is covered
by the ARC-Seal so the reporting is limited to the findings in that by the ARC-Seal so the reporting is limited to the findings in that
terminal ARC set. terminal ARC set.
10.2. Recording (local) ARC Evaluation Results 9.2. Recording (local) ARC Evaluation Results
Receivers MAY add an "arc=[pass|fail|policy]" method annotation into Receivers MAY add an "arc=[pass|fail|policy]" method annotation into
a locally-affixed Authentication-Results [RFC7601] header field along a locally-affixed Authentication-Results [RFC7601] header field along
with any salient comment(s). with any salient comment(s).
Details of the ARC chain which was evaluated should be included in Details of the ARC chain which was evaluated should be included in
the Authentication-Results and AAR headers per Section Section 5.1.1. the Authentication-Results and AAR headers per Section Section 5.2.1.
10.3. DMARC Reporting of ARC Findings - Interim 9.3. DMARC Reporting of ARC Findings - Interim
[[ Note: Discussion on the IETF DMARC-WG list has indicated some [[ Note: Discussion on the IETF DMARC-WG list has indicated some
interest in more substantial reporting for analytic purposes. To interest in more substantial reporting for analytic purposes. To
support that effort, the following guidance is provided only as an support that effort, the following guidance is provided only as an
interim, minimal data set. A more complete reporting construct will interim, minimal data set. A more complete reporting construct will
be specified in a related spec - TBD. (see the additional fields be specified in a related spec - TBD. (see the additional fields
specified in Section 5.1.1) ]] specified in Section 5.2.1) ]]
Receivers SHOULD indicate situations in which ARC evaluation Receivers SHOULD indicate situations in which ARC evaluation
influenced the results of their local policy determination. DMARC influenced the results of their local policy determination. DMARC
reporting of ARC-informed decisions can be accomplished by adding a reporting of ARC-informed decisions can be accomplished by adding a
local_policy comment explanation containing the list of data local_policy comment explanation containing the list of data
discovered in the ARC evaluation (Section 10.1 and Section 5.1.1): discovered in the ARC evaluation (Section 9.1 and Section 5.2.1):
<policy_evaluated> <policy_evaluated>
<disposition>delivered</disposition> <disposition>delivered</disposition>
<dkim>fail</dkim> <dkim>fail</dkim>
<spf>fail <comment>source.ip=10.0.0.1</comment></spf> <spf>fail <comment>source.ip=10.0.0.1</comment></spf>
<reason> <reason>
<type>local_policy</type> <type>local_policy</type>
<comment>arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example <comment>arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example
as[2].s=s2 as[1].d=d1.example as[1].s=s3</comment> as[2].s=s2 as[1].d=d1.example as[1].s=s3</comment>
</reason> </reason>
skipping to change at page 15, line 5 skipping to change at page 18, line 25
In the suggested sample, d2.example is the sealing domain for ARC[2] In the suggested sample, d2.example is the sealing domain for ARC[2]
and d1.example is the sealing domain for ARC[1]. and d1.example is the sealing domain for ARC[1].
Mediators SHOULD generate DMARC reports on messages which transit Mediators SHOULD generate DMARC reports on messages which transit
their system just like any other message which they receive. This their system just like any other message which they receive. This
will result in multiple reports for each mediated message as they will result in multiple reports for each mediated message as they
transit the series of handlers. DMARC report consumers should be transit the series of handlers. DMARC report consumers should be
aware of this behaviour and make the necessary accommodations. aware of this behaviour and make the necessary accommodations.
11. Supporting Alternate Signing Algorithms 10. Supporting Alternate Signing Algorithms
[[ Note: Some additional development of this section is needed. ]] [[ Note: Some additional development of this section is needed. ]]
In the following branch diagrams, each algorithm is represented by an In the following branch diagrams, each algorithm is represented by an
'A' or 'B' at each hop to depict the ARC chain that develops over a 'A' or 'B' at each hop to depict the ARC chain that develops over a
five hop scenario. 'x' represents a hop that does not support that five hop scenario. 'x' represents a hop that does not support that
algorithm. algorithm.
Note that during a transitional period where multiple algorithms are Note that during a transitional period where multiple algorithms are
allowed, all of the statements in this spec which refer to "exactly allowed, all of the statements in this spec which refer to "exactly
one set of ARC headers per instance" need to be understood as "at one set of ARC headers per instance" need to be understood as "at
least one set per instance and no more than one instance-set per least one set per instance and no more than one instance-set per
algorithm". algorithm".
11.1. Introductory Period 10.1. Introductory Period
Intermediaries MUST be able to validate ARC chains built with either Intermediaries MUST be able to validate ARC chains built with either
algorithm but MAY create ARC sets with either (or both) algorithm. algorithm but MAY create ARC sets with either (or both) algorithm.
The introductory period should be at least six (6) months. The introductory period should be at least six (6) months.
11.2. Co-Existence Period 10.2. Co-Existence Period
Intermediaries MUST be able to validate ARC chains build with either Intermediaries MUST be able to validate ARC chains build with either
algorithm and MUST create ARC sets with both algorithms. Chains algorithm and MUST create ARC sets with both algorithms. Chains
ending with either algorithm may be used for the result. ending with either algorithm may be used for the result.
11.3. Deprecation Period 10.3. Deprecation Period
ARC sets built with algorithms that are being deprecated MAY be ARC sets built with algorithms that are being deprecated MAY be
considered valid within an ARC chain, however, intermediaries MUST considered valid within an ARC chain, however, intermediaries MUST
NOT create additional sets with the deprecated algorithm. NOT create additional sets with the deprecated algorithm.
The deprecation period should be at least two (2) years. The deprecation period should be at least two (2) years.
11.4. Obsolescence Period 10.4. Obsolescence Period
ARC sets built with algorithms that are obsolete MUST NOT be ARC sets built with algorithms that are obsolete MUST NOT be
considered valid within an ARC chain. Intermediaries MUST NOT create considered valid within an ARC chain. Intermediaries MUST NOT create
any sets with any obsoleted algorithm. any sets with any obsoleted algorithm.
12. Privacy Considerations 11. Privacy Considerations
The ARC chain provides a verifiable record of the handlers for a The ARC chain provides a verifiable record of the handlers for a
message. Anonymous remailers will probably not find this compatible message. Anonymous remailers will probably not find this compatible
with their operating goals. with their operating goals.
13. IANA Considerations 12. IANA Considerations
This specification adds three new header fields as defined below. This specification adds three new header fields as defined below.
13.1. Authentication-Results Method Registry Update 12.1. Authentication-Results Method Registry Update
This draft adds one item to the IANA "Email Authentication Methods" This draft adds one item to the IANA "Email Authentication Methods"
registry: registry:
o Method : arc o Method : arc
Defined: [I-D.ARC] Defined: [I-D.ARC]
ptype: header ptype: header
Property: chain evaluation result Property: chain evaluation result
Value: chain evaluation result status (see Section 5.3) Value: chain evaluation result status (see Section 5.4)
Status: active Status: active
Version: 1 Version: 1
13.2. Definitions of the ARC header fields 12.2. Definitions of the ARC header fields
This specification adds three new header fields to the "Permanent This specification adds three new header fields to the "Permanent
Message Header Field Registry", as follows: Message Header Field Registry", as follows:
o Header field name: ARC-Seal o Header field name: ARC-Seal
Applicable protocol: mail Applicable protocol: mail
Status: draft Status: draft
skipping to change at page 17, line 20 skipping to change at page 20, line 41
Applicable protocol: mail Applicable protocol: mail
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [I-D.ARC] Specification document(s): [I-D.ARC]
Related information: [RFC7601] Related information: [RFC7601]
14. Security Considerations 13. Security Considerations
The Security Considerations of [RFC6376] and [RFC7601] apply directly The Security Considerations of [RFC6376] and [RFC7601] apply directly
to this specification. to this specification.
13.1. Header Size
Inclusion of ARC sets in the header of emails may cause problems for Inclusion of ARC sets in the header of emails may cause problems for
some older or more constrained MTAs if they are unable to accept the some older or more constrained MTAs if they are unable to accept the
greater size of the header. greater size of the header.
13.2. DNS Operations
Operators who receive a message bearing N ARC sets have to complete Operators who receive a message bearing N ARC sets have to complete
up to N+1 DNS queries to evaluate the chain (barring DNS redirection up to N+1 DNS queries to evaluate the chain (barring DNS redirection
mechanisms which can increase the lookups for a given target value). mechanisms which can increase the lookups for a given target value).
This has at least two effects: This has at least two effects:
1. An attacker can send a message to an ARC partipant with a 1. An attacker can send a message to an ARC partipant with a
concocted sequence of ARC sets bearing the domains of intended concocted sequence of ARC sets bearing the domains of intended
victims, and all of them will be queried by the participant until victims, and all of them will be queried by the participant until
a failure is discovered. The difficulty of forging the signature a failure is discovered. The difficulty of forging the signature
values should limit the extent of this load to domains under values should limit the extent of this load to domains under
control of the attacker. control of the attacker.
2. DKIM only does one DNS check per signature, while this one can do 2. DKIM only does one DNS check per signature, while this one can do
many (per chain). Absent caching, slow DNS responses can cause many (per chain). Absent caching, slow DNS responses can cause
SMTP timeouts; and backlogged delivery queues on mediating SMTP timeouts; and backlogged delivery queues on mediating
systems. This could be exploited as a DoS attack. systems. This could be exploited as a DoS attack.
14.1. Message Content Suspicion 13.3. Message Content Suspicion
Recipients are cautioned to treat messages bearing ARC sets with the Recipients are cautioned to treat messages bearing ARC sets with the
same suspicion that they apply to all other email messages. This same suspicion that they apply to all other email messages. This
includes appropriate content scanning and other checks for includes appropriate content scanning and other checks for
potentially malicious content. The handlers which are identified potentially malicious content. The handlers which are identified
within the ARC chain may be used to provide input to local policy within the ARC chain may be used to provide input to local policy
engines in cases where DMARC validation fails (due to mediation engines in cases where DMARC validation fails (due to mediation
impacting SPF attribution, DKIM validity or alignment). impacting SPF attribution, DKIM validity or alignment).
15. Implementation Status 14. Implementation Status
[[ Note: For minimizing section number references when the RFC editor [[ Note: For minimizing section number references when the RFC editor
removes this section, it has been moved to be the last section of the removes this section, it has been moved to be the last section of the
document before the Appendicies. ]] document before the Appendicies. ]]
[[ Note to the RFC Editor: Please remove this section before [[ Note to the RFC Editor: Please remove this section before
publication along with the reference to [RFC6982]. ]] publication along with the reference to [RFC6982]. ]]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
skipping to change at page 18, line 34 skipping to change at page 22, line 11
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
This information is known to be correct as of the seventh This information is known to be correct as of the seventh
interoperability test event which was held on 2017-07-15 & 16 at interoperability test event which was held on 2017-07-15 & 16 at
IETF99. IETF99.
15.1. GMail test reflector and incoming validation 14.1. GMail test reflector and incoming validation
Organization: Google Organization: Google
Description: Internal production implementation with both debug Description: Internal production implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Production - Incoming Validation Status of Operation: Production - Incoming Validation
Coverage: Full spec implemented as of [ARC-DRAFT-06] Coverage: Full spec implemented as of [ARC-DRAFT-06]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: Implementation Notes:
o Full functionality was demonstrated during the interop testing on o Full functionality was demonstrated during the interop testing on
2017-07-15. 2017-07-15.
Contact Info: arc-discuss@dmarc.org [1] Contact Info: arc-discuss@dmarc.org [1]
15.2. AOL test reflector and internal tagging 14.2. AOL test reflector and internal tagging
Organization: AOL Organization: AOL
Description: Internal prototype implementation with both debug Description: Internal prototype implementation with both debug
analysis and validating + sealing pass-through function analysis and validating + sealing pass-through function
Status of Operation: Beta Status of Operation: Beta
Coverage: ARC chain validity status checking is operational, but only Coverage: ARC chain validity status checking is operational, but only
applied to email addresses enrolled in the test program. This system applied to email addresses enrolled in the test program. This system
skipping to change at page 19, line 29 skipping to change at page 23, line 5
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: Implementation Notes:
o 2017-07-15: Full functionality verified during the interop o 2017-07-15: Full functionality verified during the interop
testing. testing.
Contact Info: arc-discuss@dmarc.org [2] Contact Info: arc-discuss@dmarc.org [2]
15.3. dkimpy 14.3. dkimpy
Organization: dkimpy developers/Scott Kitterman Organization: dkimpy developers/Scott Kitterman
Description: Python DKIM package Description: Python DKIM package
Status of Operation: Production Status of Operation: Production
Coverage: Coverage:
o 2017-07-15: The internal test suite is incomplete, but the command o 2017-07-15: The internal test suite is incomplete, but the command
line developmental version of validator was demonstrated to line developmental version of validator was demonstrated to
interoperate with the Google and AOL implementations during the interoperate with the Google and AOL implementations during the
interop on 2017-07-15 and the released version passes the tests in interop on 2017-07-15 and the released version passes the tests in
[ARC-TEST] (https://github.com/ValiMail/arc_test_suite) with both [ARC-TEST] (https://github.com/ValiMail/arc_test_suite) with both
python and python3. python and python3.
Licensing: Open/Other (same as dkimpy package = BCD version 2) Licensing: Open/Other (same as dkimpy package = BCD version 2)
Contact Info: https://launchpad.net/dkimpy Contact Info: https://launchpad.net/dkimpy
15.4. OpenARC 14.4. OpenARC
Organization: TDP/Murray Kucherawy Organization: TDP/Murray Kucherawy
Description: Implemention of milter functionality related to the Description: Implemention of milter functionality related to the
OpenDKIM and OpenDMARC packages OpenDKIM and OpenDMARC packages
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-06] Coverage: Built to support [ARC-DRAFT-06]
skipping to change at page 20, line 37 skipping to change at page 24, line 9
o Some issues still exist when deploying in a chained milter o Some issues still exist when deploying in a chained milter
arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC) arrangement (such as OpenSPF -> OpenDKIM -> OpenDMARC -> OpenARC)
with coordination between the stages. When deployed in a with coordination between the stages. When deployed in a
"sandwich" configuration around an MLM, there is no effective "sandwich" configuration around an MLM, there is no effective
mechanism to convey trust from the ingress (validator) to egress mechanism to convey trust from the ingress (validator) to egress
(signer) instances. (signer) instances.
Contact Info: arc-discuss@dmarc.org [3] Contact Info: arc-discuss@dmarc.org [3]
15.5. Mailman 3.1+ patch 14.5. Mailman 3.1+ patch
Organization: Mailman development team Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman 3.1+ Description: Integrated ARC capabilities within the Mailman 3.1+
package package
Status of Operation: Patch submitted Status of Operation: Patch submitted
Coverage: Unknown Coverage: Unknown
Licensing: Same as mailman package - GPL Licensing: Same as mailman package - GPL
Implementation Notes: Implementation Notes:
o Appears to work properly in at least one beta deployment, but o Appears to work properly in at least one beta deployment, but
waiting on acceptance of the pull request into the mainline of waiting on acceptance of the pull request into the mainline of
mailman development mailman development
Contact Info: https://www.gnu.org/software/mailman/contact.html Contact Info: https://www.gnu.org/software/mailman/contact.html
15.6. Copernica/MailerQ web-based validation 14.6. Copernica/MailerQ web-based validation
Organization: Copernica Organization: Copernica
Description: Web-based validation of ARC-signed messages Description: Web-based validation of ARC-signed messages
Status of Operation: Beta Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT-05] Coverage: Built to support [ARC-DRAFT-05]
Licensing: On-line usage only Licensing: On-line usage only
skipping to change at page 21, line 38 skipping to change at page 25, line 10
at http://arc.mailerq.com/ (warning - https is not supported). at http://arc.mailerq.com/ (warning - https is not supported).
o An additional instance of an ARC signature can be added if one is o An additional instance of an ARC signature can be added if one is
willing to paste a private key into an unsecured web form. willing to paste a private key into an unsecured web form.
o 2017-07-15: Testing shows that results match the other o 2017-07-15: Testing shows that results match the other
implementations listed in this section. implementations listed in this section.
Contact Info: https://www.copernica.com/ Contact Info: https://www.copernica.com/
15.7. Rspamd 14.7. Rspamd
Organization: Rspamd community Organization: Rspamd community
Description: ARC signing and verification module Description: ARC signing and verification module
Status of Operation: Production, though deployment usage is unknown Status of Operation: Production, though deployment usage is unknown
Coverage: Built to support [ARC-DRAFT-06] Coverage: Built to support [ARC-DRAFT-06]
Licensing: Open source Licensing: Open source
skipping to change at page 22, line 4 skipping to change at page 25, line 25
Status of Operation: Production, though deployment usage is unknown Status of Operation: Production, though deployment usage is unknown
Coverage: Built to support [ARC-DRAFT-06] Coverage: Built to support [ARC-DRAFT-06]
Licensing: Open source Licensing: Open source
Implementation Notes: Implementation Notes:
o 2017-06-12: Released with version 1.6.0 o 2017-06-12: Released with version 1.6.0
o 2017-07-15: Testing during the interop showed that the validation o 2017-07-15: Testing during the interop showed that the validation
functionality interoperated with the Google, AOL, dkimpy and functionality interoperated with the Google, AOL, dkimpy and
MailerQ implementations MailerQ implementations
Contact Info: https://rspamd.com/doc/modules/arc.html and Contact Info: https://rspamd.com/doc/modules/arc.html and
https://github.com/vstakhov/rspamd https://github.com/vstakhov/rspamd
15.8. PERL Mail::Milter::Authentication module 14.8. PERL Mail::Milter::Authentication module
Organization: FastMail Organization: FastMail
Description: Email domain authentication milter, previously included Description: Email domain authentication milter, previously included
SPF / DKIM / DMARC, now has ARC added SPF / DKIM / DMARC, now has ARC added
Status of Operation: Intial validation completed during IETF99 Status of Operation: Intial validation completed during IETF99
hackathon with some follow-on work during the week hackathon with some follow-on work during the week
Coverage: Built to support [I-D.ARC] Coverage: Built to support [I-D.ARC]
skipping to change at page 22, line 36 skipping to change at page 26, line 10
o 2017-07-15: Validation functionality which interoperates with o 2017-07-15: Validation functionality which interoperates with
Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
the signing functionality was reported to be working the signing functionality was reported to be working
o 2017-07-20: ARC functionality has not yet been pushed back to the o 2017-07-20: ARC functionality has not yet been pushed back to the
github repo but should be showing up soon github repo but should be showing up soon
Contact Info: https://github.com/fastmail/authentication_milter Contact Info: https://github.com/fastmail/authentication_milter
16. References 15. References
16.1. Normative References 15.1. Normative References
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, DOI 10.17487/RFC1345, June 1992, RFC 1345, DOI 10.17487/RFC1345, June 1992,
<https://www.rfc-editor.org/info/rfc1345>. <https://www.rfc-editor.org/info/rfc1345>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 24, line 29 skipping to change at page 27, line 48
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208, Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014, DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>. <https://www.rfc-editor.org/info/rfc7208>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating [RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601, Message Authentication Status", RFC 7601,
DOI 10.17487/RFC7601, August 2015, DOI 10.17487/RFC7601, August 2015,
<https://www.rfc-editor.org/info/rfc7601>. <https://www.rfc-editor.org/info/rfc7601>.
16.2. Informative References 15.2. Informative References
[ARC-DRAFT-05] [ARC-DRAFT-05]
Andersen, K., Long, B., and S. Jones, "Authenticated Andersen, K., Long, B., and S. Jones, "Authenticated
Received Chain (ARC) Protocol (I-D-06)", n.d., Received Chain (ARC) Protocol (I-D-06)", n.d.,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-06>. draft-ietf-dmarc-arc-protocol-06>.
[ARC-DRAFT-06] [ARC-DRAFT-06]
Andersen, K., Long, B., and S. Jones, "Authenticated Andersen, K., Long, B., and S. Jones, "Authenticated
Received Chain (ARC) Protocol (I-D-05)", n.d., Received Chain (ARC) Protocol (I-D-05)", n.d.,
skipping to change at page 25, line 27 skipping to change at page 29, line 5
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting, between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows", and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016, RFC 7960, DOI 10.17487/RFC7960, September 2016,
<https://www.rfc-editor.org/info/rfc7960>. <https://www.rfc-editor.org/info/rfc7960>.
16.3. URIs 15.3. URIs
[1] mailto:arc-discuss@dmarc.org [1] mailto:arc-discuss@dmarc.org
[2] mailto:arc-discuss@dmarc.org [2] mailto:arc-discuss@dmarc.org
[3] mailto:arc-discuss@dmarc.org [3] mailto:arc-discuss@dmarc.org
[4] mailto:dmarc@ietf.org [4] mailto:dmarc@ietf.org
[5] mailto:arc-discuss@dmarc.org [5] mailto:arc-discuss@dmarc.org
skipping to change at page 46, line 31 skipping to change at page 49, line 31
Brandon Long (editor) Brandon Long (editor)
Google Google
Email: blong@google.com Email: blong@google.com
Steven Jones (editor) Steven Jones (editor)
TDP TDP
Email: smj@crash.com Email: smj@crash.com
Murray Kucherawy (editor) Seth Blank (editor)
TDP ValiMail
Email: superuser@gmail.com Email: seth@valimail.com
 End of changes. 87 change blocks. 
190 lines changed or deleted 348 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/