draft-ietf-dmarc-arc-protocol-01.txt   draft-ietf-dmarc-arc-protocol-02.txt 
DMARC Working Group K. Andersen DMARC Working Group K. Andersen
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Standards Track J. Rae-Grant, Ed. Intended status: Standards Track B. Long, Ed.
Expires: June 4, 2017 B. Long, Ed. Expires: September 16, 2017 Google
Google
T. Adams, Ed.
Paypal
S. Jones, Ed. S. Jones, Ed.
TDP TDP
December 01, 2016 March 15, 2017
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-01 draft-ietf-dmarc-arc-protocol-02
Abstract Abstract
Authenticated Received Chain (ARC) permits an organization which is Authenticated Received Chain (ARC) permits an organization which is
creating or handling email to indicate its involvement with the creating or handling email to indicate its involvement with the
handling process. It defines a set of cryptographically signed handling process. It defines a set of cryptographically signed
header fields in a manner analagous to that of DKIM. Assertion of header fields in a manner analagous to that of DKIM. Assertion of
responsibility is validated through a cryptographic signature and by responsibility is validated through a cryptographic signature and by
querying the Signer's domain directly to retrieve the appropriate querying the Signer's domain directly to retrieve the appropriate
public key. Changes in the message that might break DKIM can be public key. Changes in the message that might break DKIM can be
skipping to change at page 1, line 43 skipping to change at page 1, line 40
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 June 4, 2017. This Internet-Draft will expire on September 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 27 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 4 2.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 4
2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Utility . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Utility . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Description of the New Header Fields . . . . . . . . . . 6 5.1. Description of the New Header Fields . . . . . . . . . . 6
5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 9 5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 10
5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 10 5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 11
5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 11 5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 12
5.2.1. Handling Violations in the ARC Sets . . . . . . . . . 12 5.2.1. Handling Minor Violations in the ARC Sets . . . . . . 13
5.3. Key Management and Binding . . . . . . . . . . . . . . . 12 5.2.2. Handling Major Violations in the ARC Sets . . . . . . 13
5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Key Management and Binding . . . . . . . . . . . . . . . 14
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Supporting Alternate Signing Algorithms . . . . . . . . . 14
6.2. Relationship between DKIM Signatures and ARC Headers . . 13 5.4.1. Introductory Period . . . . . . . . . . . . . . . . . 14
6.3. Validating the ARC Set of Header Fields . . . . . . . . . 13 5.4.2. Co-Existence Period . . . . . . . . . . . . . . . . . 14
6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 13 5.4.3. Deprecation Period . . . . . . . . . . . . . . . . . 14
6.4.1. Assessing Chain Validity Violations . . . . . . . . . 13 5.4.4. Obsolescence Period . . . . . . . . . . . . . . . . . 15
6.4.2. Responding to ARC Validity Violations . . . . . . . . 14 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4.3. Recording the Results of ARC Evaluation . . . . . . . 14 6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 15
6.4.4. Output Data Points from ARC Evaluation . . . . . . . 14 6.2. Relationship between DKIM Signatures and ARC Headers . . 15
6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 14 6.3. Validating the ARC Set of Header Fields . . . . . . . . . 15
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.4.1. Assessing Chain Validity Violations . . . . . . . . . 15
8.1. Authentication-Results Method Registry Update . . . . . . 15 6.4.2. Responding to ARC Validity Violations . . . . . . . . 16
8.2. Definitions of the ARC header fields . . . . . . . . . . 15 6.4.3. Recording the Results of ARC Evaluation . . . . . . . 16
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 6.4.4. Output Data Points from ARC Evaluation . . . . . . . 16
9.1. GMail test reflector . . . . . . . . . . . . . . . . . . 17 6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 16
9.2. AOL test reflector and internal tagging . . . . . . . . . 17 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
9.3. dkimpy patch . . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Authentication-Results Method Registry Update . . . . . . 17
9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 19 8.2. Definitions of the ARC header fields . . . . . . . . . . 17
9.6. Copernica/MailerQ web-based validation . . . . . . . . . 19 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9.1. GMail test reflector and incoming validation . . . . . . 19
10.1. Message Content Suspicion . . . . . . . . . . . . . . . 20 9.2. AOL test reflector and internal tagging . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 22 9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 21
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.6. Copernica/MailerQ web-based validation . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10.1. Message Content Suspicion . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 24
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Appendix A - Example Usage (Obsolete but retained Appendix A. Appendix A - Example Usage (Obsolete but retained
for illustrative purposes) . . . . . . . . . . . . . 23 for illustrative purposes) . . . . . . . . . . . . . 25
A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 23 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 25
A.1.1. Here's the message as it exits the Origin: . . . . . 23 A.1.1. Here's the message as it exits the Origin: . . . . . 25
A.1.2. Message is then received at example.org . . . . . . . 24 A.1.2. Message is then received at example.org . . . . . . . 26
A.1.3. Example 1: Message received by Recipient . . . . . . 26 A.1.3. Example 1: Message received by Recipient . . . . . . 28
A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 27 A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 29
A.2.1. Here's the message as it exits the Origin: . . . . . 27 A.2.1. Here's the message as it exits the Origin: . . . . . 29
A.2.2. Message is then received at example.org . . . . . . . 28 A.2.2. Message is then received at example.org . . . . . . . 30
A.2.3. Example 2: Message received by Recipient . . . . . . 32 A.2.3. Example 2: Message received by Recipient . . . . . . 34
A.3. Example 3: Mailing list to forwarded mailbox with source 34 A.3. Example 3: Mailing list to forwarded mailbox with source 36
A.3.1. Here's the message as it exits the Origin: . . . . . 34 A.3.1. Here's the message as it exits the Origin: . . . . . 36
A.3.2. Message is then received at example.org . . . . . . . 35 A.3.2. Message is then received at example.org . . . . . . . 37
A.3.3. Example 3: Message received by Recipient . . . . . . 40 A.3.3. Example 3: Message received by Recipient . . . . . . 42
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 44
Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 43 Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
The development of strong domain authentication through Sender Policy The development of strong domain authentication through Sender Policy
Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM)
[RFC6376] has led to the implementation of the DMARC framework [RFC6376] has led to the implementation of the DMARC framework
[RFC7489] which extends the authentication to the author's "From:" [RFC7489] which extends the authentication to the author's "From:"
(RFC5322.From) field and permits publishing policies for non- (RFC5322.From) field and permits publishing policies for non-
compliant messages. Implicit within the DMARC framework is a compliant messages. Implicit within the DMARC framework is a
requirement that any intermediaries between the source system and requirement that any intermediaries between the source system and
skipping to change at page 7, line 12 skipping to change at page 7, line 12
o a = hash algorithm; syntax is the same as the "a=" tag defined in o a = hash algorithm; syntax is the same as the "a=" tag defined in
Section 3.5 of [RFC6376]; Section 3.5 of [RFC6376];
o b = digital signature; syntax is the same as the "b=" tag defined o b = digital signature; syntax is the same as the "b=" tag defined
in Section 3.5 of [RFC6376]; in Section 3.5 of [RFC6376];
o cv = chain validation status: valid values: o cv = chain validation status: valid values:
* 'none' = no pre-existing chain; * 'none' = no pre-existing chain;
* 'invalid' = a pre-existing chain is malformed beyond
interpretation;
* 'fail' = the chain as received does not validate; or * 'fail' = the chain as received does not validate; or
* 'pass' = valid chain received. * 'pass' = valid chain received.
o d = domain for key; syntax is the same as the "d=" tag defined in o d = domain for key; syntax is the same as the "d=" tag defined in
Section 3.5 of [RFC6376]; Section 3.5 of [RFC6376];
o i = "instance" or sequence number; monotonically increasing at o i = "instance" or sequence number; monotonically increasing at
each "sealing" entity, beginning with '1', may not exceed '1024' each "sealing" entity, beginning with '1', see Section 5.1.1.1.1
regarding the valid range
o s = selector for key; syntax is the same as the "s=" tag defined o s = selector for key; syntax is the same as the "s=" tag defined
in Section 3.5 of [RFC6376]; in Section 3.5 of [RFC6376];
o t = timestamp; syntax is the same as the "t=" tag defined in o t = timestamp; syntax is the same as the "t=" tag defined in
Section 3.5 of [RFC6376]. Section 3.5 of [RFC6376].
5.1.1.1.1. Valid Range for "Instance" 'i' Tag Value
5.1.1.1.1.1. Minimum 'i' Tag Value
The minimum valid 'i' tag value is one (1).
5.1.1.1.1.2. Maximum 'i' Tag Value
ARC implementations MUST support at least ten (10) intermediary
steps.
More than fifty (50) intermediaries is considered extremely unlikely
so ARC chains with more than fifty intermediaries may be marked with
"cv=invalid".
The maximum valid 'i' tag value is 1024, but values more that the
supported number of intermediaries are meaningless.
5.1.1.2. Differences between DKIM-Signature and ARC-Seal 5.1.1.2. Differences between DKIM-Signature and ARC-Seal
No 'bh' value is defined for ARC-Seal, since only message header No 'bh' value is defined for ARC-Seal, since only message header
fields are ever signed by the ARC-Seal. fields are ever signed by the ARC-Seal.
ARC-Seal does not use the 'h' tag (the list of signed header fields) ARC-Seal does not use the 'h' tag (the list of signed header fields)
that is defined for DKIM-Signatures because the list of applicable that is defined for DKIM-Signatures because the list of applicable
header fields is fully determined by the construction rules (see header fields is fully determined by the construction rules (see
Section 5.1.1.3). Section 5.1.1.3).
ARC-Seal does not use the 'c' (canonicalization) tag because only ARC-Seal does not use the 'c' (canonicalization) tag because only
'relaxed' canonicalization [RFC6376] is allowed for ARC-Seal header 'relaxed' canonicalization [RFC6376] is allowed for ARC-Seal header
field canonicalization. field canonicalization.
5.1.1.3. Deterministic 'h' Value for ARC-Seal 5.1.1.3. Deterministic (Implicit) 'h' Tag Value for ARC-Seal
In this section, the term "scope" is used to indicate those header In this section, the term "scope" is used to indicate those header
fields signed by an ARC-Seal header field. A number in parentheses fields signed by an ARC-Seal header field. A number in parentheses
indicates the instance of that field, starting at 1. The suffix "- indicates the instance of that field, starting at 1. The suffix "-
no-b" is used with an ARC-Seal field to indicate that its "b" field no-b" is used with an ARC-Seal field to indicate that its "b" field
is empty at the time the signature is computed, as described in is empty at the time the signature is computed, as described in
Section 3.5 of [RFC6376]. "AAR" refers to ARC-Authentication- Section 3.5 of [RFC6376]. "AAR" refers to ARC-Authentication-
Results, "AMS" to ARC-Message-Signature, "AS" to ARC-Seal, and "ASB" Results, "AMS" to ARC-Message-Signature, "AS" to ARC-Seal, and "ASB"
to an ARC-Seal with an empty "b" tag. to an ARC-Seal with an empty "b" tag.
skipping to change at page 8, line 41 skipping to change at page 9, line 22
In particular, signing calculation MUST be done in bottom-up order as In particular, signing calculation MUST be done in bottom-up order as
specified in Section 5.4.2 of [RFC6376] and as illustrated above specified in Section 5.4.2 of [RFC6376] and as illustrated above
Section 5.1.1.3. Section 5.1.1.3.
5.1.1.5. Determining the 'cv' Tag Value for ARC-Seal 5.1.1.5. Determining the 'cv' Tag Value for ARC-Seal
In order for a series of ARC sets to be considered valid, the In order for a series of ARC sets to be considered valid, the
following statements MUST be satisfied: following statements MUST be satisfied:
1. All ARC-Seal header fields MUST validate; 1. The chain of ARC sets must have structural integrity (no sets or
set component header fields missing, no duplicates, excessive
hops (cf. Section 5.1.1.1.1), etc.);
2. All ARC-Seal header fields MUST have a chain value (cv=) status 2. All ARC-Seal header fields MUST validate;
3. All ARC-Seal header fields MUST have a chain value (cv=) status
of "pass" (except the first which MUST be "none"); and of "pass" (except the first which MUST be "none"); and
3. The newest (highest instance number (i=)) AMS header field MUST 4. The newest (highest instance number (i=)) AMS header field MUST
validate. validate.
5.1.1.5.1. Pseudocode to Determine Chain Value Status: 5.1.1.5.1. Pseudocode to Determine Chain Value Status:
In the algorith below, a "hop" is represented by the ARC set bearing In the algorith below, a "hop" is represented by the ARC set bearing
a particular instance number. The number of hops is the same as the a particular instance number. The number of hops is the same as the
highest instance number found in the ARC sets, or 0 (zero) if there highest instance number found in the ARC sets, or 0 (zero) if there
are no ARC sets found within the header. are no ARC sets found within the header.
"Success" means that the signature found in the referenced header "Success" means that the signature found in the referenced header
validates when against the content which was signed. validates when against the content which was signed.
if (num_hops == 0) { if (lastest_hop.AS.cv == "invalid") {
terminate analysis - no further ARC processing
}
if (chain not structurally valid) {
return "invalid"
} else if (num_hops == 0) {
return "none" return "none"
} else { } else {
if (validate(latest_hop.AMS) != success) { if (validate(latest_hop.AMS) != success) {
return "fail" return "fail"
} else { } else {
// note that instance is always >= 1 by definition // note that instance is always >= 1 by definition
for each hop (from highest instance to lowest) { for each hop (from highest instance to lowest) {
if ((hop_num > 1 and hop.ARC-Seal.cv == "pass") or if ((hop_num > 1 and hop.ARC-Seal.cv == "pass") or
(hop_num == 1 and hop.ARC-Seal.cv == "none")) { (hop_num == 1 and hop.ARC-Seal.cv == "none")) {
if (validate(hop.ARC-Seal) != success) { if (validate(hop.ARC-Seal) != success) {
skipping to change at page 11, line 44 skipping to change at page 12, line 38
reference. reference.
3. The associated ARC-Authentication-Results header field (matching 3. The associated ARC-Authentication-Results header field (matching
i= value) MUST be the last item in the list for each set of ARC i= value) MUST be the last item in the list for each set of ARC
header fields. header fields.
Thus, when prefixing ARC header fields to the existing header, Thus, when prefixing ARC header fields to the existing header,
1. the AAR header would be prefixed first; then 1. the AAR header would be prefixed first; then
2. the AMS would be calculated and prefixed; 2. the AMS would be calculated and prefixed (above the AAR);
3. lastly the AS would be calculated and prefixed. 3. lastly the AS would be calculated and prefixed (above the AMS).
The ARC-Message-Signature field(s) MUST not include any of the ARC- The ARC-Message-Signature field(s) MUST not include any of the ARC-
Seal header field(s) (from prior ARC sets) in their signing scope in Seal header field(s) (from prior ARC sets) in their signing scope in
order maintain a separation of responsibilities. When adding an ARC- order maintain a separation of responsibilities. When adding an ARC-
Authentication-Results header field, it MUST be added before Authentication-Results header field, it MUST be added before
computing the ARC-Message-Signature. When "sealing" the message, an computing the ARC-Message-Signature. When "sealing" the message, an
operator MUST create and attach the ARC-Message-Signature before the operator MUST create and attach the ARC-Message-Signature before the
ARC-Seal in order to reference it and embed the ARC-Message-Signature ARC-Seal in order to reference it and embed the ARC-Message-Signature
within the ARC-Seal signature scope. within the ARC-Seal signature scope.
Each ARC-Seal is connected to its respective ARC-Message-Signature Each ARC-Seal is connected to its respective ARC-Message-Signature
and ARC-Authentication-Results through the common value of the "i=" and ARC-Authentication-Results through the common value of the "i="
tag. tag.
5.2.1. Handling Violations in the ARC Sets 5.2.1. Handling Minor Violations in the ARC Sets
When ordering the ARC header field sets, if there are gross When ordering the ARC header field sets, misordering of header fields
violations of this protocol (e.g., such as duplicated instance MUST be resolved as follows:
numbers), such header field set(s) MUST be ordered as follows when
analyzing for validity or subsequent signing:
o Within each set, header fields are sorted as specified in o Within each set, header fields are sorted as specified in
Section 5.2; then Section 5.2; then
o Any ARC sets that are complete duplicates are removed - leaving o Any remaining order dependencies between sets (e.g., such as
only one instance of each unique ARC set; then different hash algorithms) MUST be ordered as follows:
o Any remaining order dependencies between sets are be ordered as
follows:
1. (First) By descending order of i=; then 1. (First) By descending order of i=; then
2. (Second) By descending order of t= (from the ARC-Seal header 2. (Second) By descending order of t= (from the ARC-Seal header
field within the set); then field within the set); then
3. (Finally) By ascending US-ASCII [RFC1345] sort order for the 3. (Finally) By ascending US-ASCII [RFC1345] sort order for the
entire canonicalized header field set entire canonicalized header field set
The intent of specifying this ordering is to allow downstream message The intent of specifying this ordering is to allow downstream message
handlers to add their own ARC sets in a deterministic manner and to handlers to add their own ARC sets in a deterministic manner and to
provide some resiliance against misbehaving downstream MTAs. provide some resiliance against downstream MTAs which may reorder
header fields.
5.2.2. Handling Major Violations in the ARC Sets
Gross violations of the ARC protocol definition (e.g., such as
duplicated instance numbers or missing header fields or header field
sets) MUST be terminated by the detecting system setting 'cv=invalid'
in the ARC-Seal header. The status of the ARC evaluation reported in
the corresponding AAR header field MUST be 'unknown'.
Because the violations can not be readily enumerated, the header
fields signed by the AS header field in the case of a major violation
MUST be only the matching 'i=' instance headers created by the MTA
which detected the malformed chain, as if this newest ARC set was the
only set present.
Downstream MTAs SHOULD NOT attempt any analysis on an ARC chain that
has been marked 'invalid'.
5.3. Key Management and Binding 5.3. Key Management and Binding
The public keys for ARC header fields follow the same requirements The public keys for ARC header fields follow the same requirements
and semantics as those for DKIM-Signatures, described in Section 3.6 and semantics as those for DKIM-Signatures, described in Section 3.6
of [RFC6376]. Operators may use distinct selectors for the ARC of [RFC6376]. Operators may use distinct selectors for the ARC
header fields at their own discretion. header fields at their own discretion.
5.3.1. Namespace 5.3.1. Namespace
All ARC-related keys are stored in the same namespace as DKIM keys All ARC-related keys are stored in the same namespace as DKIM keys
[RFC6376]: "_domainkey" specifically by adding the "._domainkey" [RFC6376]: "_domainkey" specifically by adding the "._domainkey"
suffix to the name of the key (the "selector"). For example, given suffix to the name of the key (the "selector"). For example, given
an ARC-Seal (or ARC-Message-Signature) field of a "d=" tag value of an ARC-Seal (or ARC-Message-Signature) field of a "d=" tag value of
"example.com" and an "s=" value of "foo.bar", the DNS query seeking "example.com" and an "s=" value of "foo.bar", the DNS query seeking
the public key will a query at the name the public key will a query at the name
"foo.bar._domainkey.example.com". "foo.bar._domainkey.example.com".
5.4. Supporting Alternate Signing Algorithms
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
five hop scenario. 'x' represents a hop that does not support that
algorithm.
5.4.1. Introductory Period
Intermediaries MUST be able to validate ARC chains build with either
algorithm but MAY create ARC sets with either (or both) algorithm.
The introductory period should be at least six (6) months.
5.4.2. Co-Existence Period
Intermediaries MUST be able to validate ARC chains build with either
algorithm and MUST create ARC sets with both algorithms. Chains
ending with either algorithm may be used for the result.
5.4.3. Deprecation Period
ARC sets built with algorithms that are being deprecated MAY be
considered valid within an ARC chain, however, intermediaries MUST
not create additional sets with the deprecated algorithm.
The deprecation period should be at least two (2) years.
5.4.4. Obsolescence Period
ARC sets which are created with obsolete algorithms must be ignored.
6. Usage 6. Usage
For a more thorough treatment of the recommended usage of the ARC For a more thorough treatment of the recommended usage of the ARC
header fields for both intermediaries and end receivers, please header fields for both intermediaries and end receivers, please
consult [ARC-USAGE]. consult [ARC-USAGE].
6.1. Participation 6.1. Participation
The inclusion of additional ARC sets is to be done whenever a trust The inclusion of additional ARC sets is to be done whenever a trust
boundary is crossed, and especially when prior DKIM-Signatures might boundary is crossed, and especially when prior DKIM-Signatures might
skipping to change at page 17, line 8 skipping to change at page 19, line 8
According to [RFC6982], "this will allow reviewers and working groups According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
This information is known to be correct as of the third This information is known to be correct as of the third
interoperability test event which was held on 2016-06-17. interoperability test event which was held on 2016-06-17.
9.1. GMail test reflector 9.1. GMail test reflector and incoming validation
Organization: Google Organization: Google
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: Production - Incoming Validation
Coverage: Full spec implemented as of [ARC-DRAFT] Coverage: Full spec implemented as of [ARC-DRAFT]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: Full functionality was demonstrated during the Implementation Notes: Full functionality was demonstrated during the
interop testing on 2016-06-17 interop testing on 2016-06-17
In place for reporting usage only as of 2016-11-21 on all GMail In place for reporting usage only as of 2016-11-21 on all GMail
flows. flows.
Rechecked general incoming validation as of 2017-02-24 interop event.
Contact Info: arc-discuss@dmarc.org [1] Contact Info: arc-discuss@dmarc.org [1]
9.2. AOL test reflector and internal tagging 9.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: Alpha Status of Operation: Beta
Coverage: ARC chain validity status checking is not operational, but Coverage: ARC chain validity status checking is not operational, but
otherwise this system conforms to [ARC-DRAFT] otherwise this system conforms to [ARC-DRAFT]
Licensing: Proprietary - Internal only Licensing: Proprietary - Internal only
Implementation Notes: Full functionality with the exception of chain Implementation Notes: Full functionality with the exception of chain
validity checking was demonstrated during the interop testing on validity checking was demonstrated during the interop testing on
2016-06-17 2016-06-17
Available for production mail via selected account whitelisting for Available for production mail via selected account whitelisting for
test validation only. test validation only.
Intermittent stability problems discovered at the interop event on
2017-02-24. Remediation underway as of the publication of this
draft.
Contact Info: arc-discuss@dmarc.org [2] Contact Info: arc-discuss@dmarc.org [2]
9.3. dkimpy patch 9.3. dkimpy
Organization: OAR-DEV Organization: dkimpy developers
Description: Patches to the dkimpy (Python DKIM) package Description: Python DKIM package
[https://code.launchpad.net/~dkimpy-hackers/dkimpy/trunk] to add ARC
functionality
Status of Operation: Beta Status of Operation: Production
Coverage: The test suite is incomplete, but the command line Coverage: The internal test suite is incomplete, but the command line
validator was demonstrated to interoperate with the Google and AOL developmental version of validator was demonstrated to interoperate
implementations during the interop on 2016-06-17 with the Google and AOL implementations during the interop on
2016-06-17 and the released version passes the tests in [ARC-TEST]
https://github.com/ValiMail/arc_test_suite with both python and
python3.
Licensing: Open/Other (same as dkimpy package) Licensing: Open/Other (same as dkimpy package)
Implementation Notes: The patch has been submitted to the dkimpy Contact Info: https://launchpad.net/dkimpy
maintainer for inclusion into the official package.
Released to the community as of 2016-11-12 at
[https://code.launchpad.net/~dkimpy-hackers/dkimpy/trunk]
Contact Info: arc-discuss@dmarc.org [3]
9.4. OpenARC 9.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: Alpha Status of Operation: Beta
Coverage: Built to support [ARC-DRAFT] Coverage: Built to support [ARC-DRAFT]
Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages) Licensing: Open/Other (same as OpenDKIM and OpenDMARC packages)
Implementation Notes: The build is FreeBSD oriented and takes some Implementation Notes: The build is FreeBSD oriented and takes some
tweaks to build on RedHat-based Linux platforms. Initial testing tweaks to build on RedHat-based Linux platforms.
during the interop event on 2016-06-17 showed that it can be
operational, but the documentation regarding configuration settings
is unclear and the generated signature values do not validate when
compared to the Google, AOL or dkimpy implementations.
Contact Info: arc-discuss@dmarc.org [4] Initial testing during the
interop event on 2016-06-17 showed that it can be operational, but the
documentation regarding configuration settings is unclear and the
generated signature values do not validate when compared to the Google,
AOL or dkimpy implementations.
Testing during the 2017-02-24 interop event showed that some of the
problems have been fixed, but there are still interoperability problems
when trying to use OpenARC in a "sandwich" configuration around a MLM.
Contact Info: arc-discuss@dmarc.org [3]
9.5. Mailman addition 9.5. Mailman addition
Organization: Mailman development team Organization: Mailman development team
Description: Integrated ARC capabilities within the Mailman package Description: Integrated ARC capabilities within the Mailman package
Status of Operation: Implementation in progress Status of Operation: Patch submitted
Coverage: Unknown Coverage: Unknown
Licensing: Same as mailman package - GPL Licensing: Same as mailman package - GPL
Implementation Notes: Incomplete at this time Implementation Notes: Incomplete at this time
Contact Info: [https://www.gnu.org/software/mailman/contact.html] Contact Info: [https://www.gnu.org/software/mailman/contact.html]
9.6. Copernica/MailerQ web-based validation 9.6. Copernica/MailerQ web-based validation
skipping to change at page 20, line 42 skipping to change at page 23, line 6
11. References 11. References
11.1. Normative References 11.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,
<http://www.rfc-editor.org/info/rfc1345>. <http://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/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
<http://www.rfc-editor.org/info/rfc2142>. <http://www.rfc-editor.org/info/rfc2142>.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
<http://www.rfc-editor.org/info/rfc2606>. <http://www.rfc-editor.org/info/rfc2606>.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
RFC 3463, DOI 10.17487/RFC3463, January 2003, 3463, DOI 10.17487/RFC3463, January 2003,
<http://www.rfc-editor.org/info/rfc3463>. <http://www.rfc-editor.org/info/rfc3463>.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686, Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
September 2006, <http://www.rfc-editor.org/info/rfc4686>. September 2006, <http://www.rfc-editor.org/info/rfc4686>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
DOI 10.17487/RFC5234, January 2008, RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>. <http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI
DOI 10.17487/RFC5322, October 2008, 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <http://www.rfc-editor.org/info/rfc5322>.
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", RFC 5585, Identified Mail (DKIM) Service Overview", RFC 5585, DOI
DOI 10.17487/RFC5585, July 2009, 10.17487/RFC5585, July 2009,
<http://www.rfc-editor.org/info/rfc5585>. <http://www.rfc-editor.org/info/rfc5585>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI
DOI 10.17487/RFC5598, July 2009, 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>. <http://www.rfc-editor.org/info/rfc5598>.
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
"DomainKeys Identified Mail (DKIM) Development, "DomainKeys Identified Mail (DKIM) Development,
Deployment, and Operations", RFC 5863, Deployment, and Operations", RFC 5863, DOI 10.17487/
DOI 10.17487/RFC5863, May 2010, RFC5863, May 2010,
<http://www.rfc-editor.org/info/rfc5863>. <http://www.rfc-editor.org/info/rfc5863>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>. <http://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <http://www.rfc-editor.org/info/rfc6377>. September 2011, <http://www.rfc-editor.org/info/rfc6377>.
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
(DKIM) for Failure Reporting", RFC 6651, (DKIM) for Failure Reporting", RFC 6651, DOI 10.17487/
DOI 10.17487/RFC6651, June 2012, RFC6651, June 2012,
<http://www.rfc-editor.org/info/rfc6651>. <http://www.rfc-editor.org/info/rfc6651>.
[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,
<http://www.rfc-editor.org/info/rfc7208>. <http://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/
DOI 10.17487/RFC7601, August 2015, RFC7601, August 2015,
<http://www.rfc-editor.org/info/rfc7601>. <http://www.rfc-editor.org/info/rfc7601>.
11.2. Informative References 11.2. Informative References
[ARC-DRAFT] [ARC-DRAFT]
Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S. Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S.
Jones, "Authenticated Received Chain (ARC) Protocol Jones, "Authenticated Received Chain (ARC) Protocol
(I-D-05)", June 2016, <https://tools.ietf.org/html/draft- (I-D-05)", June 2016, <https://tools.ietf.org/html/draft-
ietf-dmarc-arc-protocol-00>. ietf-dmarc-arc-protocol-00>.
[ARC-TEST]
Blank, S., "ARC Test Suite", January 2017,
<https://github.com/ValiMail/arc_test_suite>.
[ARC-USAGE] [ARC-USAGE]
Jones, S., Adams, T., Rae-Grant, J., and K. Andersen, Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
"Recommended Usage of the ARC Headers", June 2016, "Recommended Usage of the ARC Headers", December 2017,
<https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage- <https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-
00>. 01>.
[DMARC-INTEROP] [DMARC-INTEROP]
Martin, F., Lear, E., Draegen, T., Zwicky, E., and K. Martin, F., Lear, E., Draegen, T., Zwicky, E., and K.
Andersen, "Interoperability Issues Between DMARC and Andersen, "Interoperability Issues Between DMARC and
Indirect Email Flows", June 2016, Indirect Email Flows", June 2016,
<https://tools.ietf.org/html/draft-ietf-dmarc- <https://tools.ietf.org/html/draft-ietf-dmarc-
interoperability-17>. interoperability-17>.
[ENHANCED-STATUS] [ENHANCED-STATUS]
"IANA SMTP Enhanced Status Codes", n.d., "IANA SMTP Enhanced Status Codes", n.d.,
<http://www.iana.org/assignments/smtp-enhanced-status- <http://www.iana.org/assignments/smtp-enhanced-status-
codes/smtp-enhanced-status-codes.xhtml>. codes/smtp-enhanced-status-codes.xhtml>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, Code: The Implementation Status Section", RFC 6982, DOI
DOI 10.17487/RFC6982, July 2013, 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <http://www.rfc-editor.org/info/rfc6982>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>. <http://www.rfc-editor.org/info/rfc7489>.
11.3. URIs 11.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:arc-discuss@dmarc.org [4] mailto:dmarc@ietf.org
[5] mailto:dmarc@ietf.org
[6] mailto:arc-discuss@dmarc.org [5] mailto:arc-discuss@dmarc.org
Appendix A. Appendix A - Example Usage (Obsolete but retained for Appendix A. Appendix A - Example Usage (Obsolete but retained for
illustrative purposes) illustrative purposes)
[[ Note: The following examples were mocked up early in the [[ Note: The following examples were mocked up early in the
definition process for the spec. They no longer reflect the current definition process for the spec. They no longer reflect the current
definition and need various updates. ]] definition and need various updates. ]]
A.1. Example 1: Simple mailing list A.1. Example 1: Simple mailing list
skipping to change at page 43, line 8 skipping to change at page 45, line 8
Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck Alex Brotman, Brandon Long, Dave Crocker, Elizabeth Zwicky, Franck
Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer, Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
Mike Jones, Steve Jones, Terry Zink, Tim Draegen. Mike Jones, Steve Jones, Terry Zink, Tim Draegen.
Grateful appreciation is extended to the people who provided feedback Grateful appreciation is extended to the people who provided feedback
through the discuss mailing list. through the discuss mailing list.
Appendix C. Comments and Feedback Appendix C. Comments and Feedback
Please address all comments, discussions, and questions to Please address all comments, discussions, and questions to
dmarc@ietf.org [5]. Earlier discussions can be found at arc- dmarc@ietf.org [4]. Earlier discussions can be found at arc-
discuss@dmarc.org [6]. discuss@dmarc.org [5].
Authors' Addresses Authors' Addresses
Kurt Andersen Kurt Andersen
LinkedIn LinkedIn
2029 Stierlin Ct. 1000 West Maude Ave
Mountain View, California 94043 Sunnyvale, California 94043
USA USA
Email: kurta@linkedin.com Email: kurta@linkedin.com
John Rae-Grant (editor)
Google
Email: johnrg@google.com
Brandon Long (editor) Brandon Long (editor)
Google Google
Email: blong@google.com Email: blong@google.com
J. Trent Adams (editor)
Paypal
Email: trent.adams@paypal.com
Steven Jones (editor) Steven Jones (editor)
TDP TDP
Email: smj@crash.com Email: smj@crash.com
 End of changes. 56 change blocks. 
144 lines changed or deleted 223 lines changed or added

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