draft-ietf-dmarc-arc-protocol-04.txt   draft-ietf-dmarc-arc-protocol-05.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: December 22, 2017 Google Expires: January 1, 2018 Google
S. Jones, Ed. S. Jones, Ed.
TDP TDP
June 20, 2017 June 30, 2017
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-04 draft-ietf-dmarc-arc-protocol-05
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 40 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 December 22, 2017. This Internet-Draft will expire on January 1, 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
(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
skipping to change at page 2, line 41 skipping to change at page 2, line 41
5.4.1. Introductory Period . . . . . . . . . . . . . . . . . 14 5.4.1. Introductory Period . . . . . . . . . . . . . . . . . 14
5.4.2. Co-Existence Period . . . . . . . . . . . . . . . . . 14 5.4.2. Co-Existence Period . . . . . . . . . . . . . . . . . 14
5.4.3. Deprecation Period . . . . . . . . . . . . . . . . . 14 5.4.3. Deprecation Period . . . . . . . . . . . . . . . . . 14
5.4.4. Obsolescence Period . . . . . . . . . . . . . . . . . 14 5.4.4. Obsolescence Period . . . . . . . . . . . . . . . . . 14
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Relationship between DKIM Signatures and ARC Headers . . 15 6.2. Relationship between DKIM Signatures and ARC Headers . . 15
6.3. Validating the ARC Set of Header Fields . . . . . . . . . 15 6.3. Validating the ARC Set of Header Fields . . . . . . . . . 15
6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 15 6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 15
6.4.1. Assessing Chain Validity Violations . . . . . . . . . 15 6.4.1. Assessing Chain Validity Violations . . . . . . . . . 15
6.4.2. Responding to ARC Validity Violations . . . . . . . . 15 6.4.2. Responding to ARC Validity Violations . . . . . . . . 16
6.4.3. Recording the Results of ARC Evaluation . . . . . . . 16 6.4.3. Recording the Results of ARC Evaluation . . . . . . . 16
6.4.4. Output Data Points from ARC Evaluation . . . . . . . 16 6.4.4. Output Data Points from ARC Evaluation . . . . . . . 16
6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 16 6.4.5. Reporting ARC Effects for DMARC Local Policy -
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 Interim . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. Authentication-Results Method Registry Update . . . . . . 17 8.1. Authentication-Results Method Registry Update . . . . . . 17
8.2. Definitions of the ARC header fields . . . . . . . . . . 17 8.2. Definitions of the ARC header fields . . . . . . . . . . 17
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
9.1. GMail test reflector and incoming validation . . . . . . 18 9.1. GMail test reflector and incoming validation . . . . . . 19
9.2. AOL test reflector and internal tagging . . . . . . . . . 19 9.2. AOL test reflector and internal tagging . . . . . . . . . 19
9.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 20 9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 21
9.6. Copernica/MailerQ web-based validation . . . . . . . . . 21 9.6. Copernica/MailerQ web-based validation . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10.1. Message Content Suspicion . . . . . . . . . . . . . . . 22 10.1. Message Content Suspicion . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 24
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 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) . . . . . . . . . . . . . 25 for illustrative purposes) . . . . . . . . . . . . . 25
A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 25 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 25
A.1.1. Here's the message as it exits the Origin: . . . . . 25 A.1.1. Here's the message as it exits the Origin: . . . . . 25
A.1.2. Message is then received at example.org . . . . . . . 26 A.1.2. Message is then received at example.org . . . . . . . 26
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 * 'fail' = the chain as received does not or can not validate; or
interpretation;
* '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', see Section 5.1.1.1.1 each "sealing" entity, beginning with '1', see Section 5.1.1.1.1
regarding the valid range regarding the valid range
skipping to change at page 7, line 45 skipping to change at page 7, line 42
The minimum valid 'i' tag value is one (1). The minimum valid 'i' tag value is one (1).
5.1.1.1.1.2. Maximum 'i' Tag Value 5.1.1.1.1.2. Maximum 'i' Tag Value
ARC implementations MUST support at least ten (10) intermediary ARC implementations MUST support at least ten (10) intermediary
steps. steps.
More than fifty (50) intermediaries is considered extremely unlikely More than fifty (50) intermediaries is considered extremely unlikely
so ARC chains with more than fifty intermediaries may be marked with so ARC chains with more than fifty intermediaries may be marked with
"cv=invalid". "cv=fail".
The maximum valid 'i' tag value is 1024, but values more that the The maximum valid 'i' tag value is 1024, but values more that the
supported number of intermediaries are meaningless. 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)
skipping to change at page 9, line 42 skipping to change at page 9, line 34
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 checked against the specified content.
if (lastest_hop.AS.cv == "invalid") { if (lastest_hop.AS.cv == "fail") {
terminate analysis - no further ARC processing terminate analysis - no further ARC processing
} }
if (chain not structurally valid) { if (chain not structurally valid) {
return "invalid" return "fail"
} else if (num_hops == 0) { } 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")) {
skipping to change at page 13, line 33 skipping to change at page 13, line 33
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 downstream MTAs which may reorder provide some resiliance against downstream MTAs which may reorder
header fields. header fields.
5.2.2. Handling Major Violations in the ARC Sets 5.2.2. Handling Major Violations in the ARC Sets
Gross violations of the ARC protocol definition (e.g., such as Gross violations of the ARC protocol definition (e.g., such as
duplicated instance numbers or missing header fields or header field duplicated instance numbers or missing header fields or header field
sets) MUST be terminated by the detecting system setting 'cv=invalid' sets) MUST be terminated by the detecting system setting 'cv=fail' in
in the ARC-Seal header. The status of the ARC evaluation reported in the ARC-Seal header. The status of the ARC evaluation reported in
the corresponding AAR header field MUST be 'unknown'. the corresponding AAR header field MUST be 'unknown'.
Because the violations can not be readily enumerated, the header Because the violations can not be readily enumerated, the header
fields signed by the AS header field in the case of a major violation 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 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 which detected the malformed chain, as if this newest ARC set was the
only set present. only set present.
Downstream MTAs SHOULD NOT attempt any analysis on an ARC chain that Downstream MTAs SHOULD NOT attempt any analysis on an ARC chain that
has been marked 'invalid'. has been marked 'fail'.
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
skipping to change at page 15, line 12 skipping to change at page 15, line 12
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
not survive the handling being performed such as some mailing lists not survive the handling being performed such as some mailing lists
that modify the content of messages or some gateway transformations. that modify the content of messages or some gateway transformations.
Note that trust boundaries might or might not exactly correspond with Note that trust boundaries might or might not exactly correspond with
ADMD boundaries. ADMD boundaries. Some organizations may have internal trust
boundaries within a single ADMD or have trust boundaries which span
more than one ADMD.
Each participating ADMD MUST validate the preceding ARC set as a part Each participating ADMD MUST validate the preceding ARC set as a part
of asserting their own seal. Even if the set is determined to be of asserting their own seal. Until the chain is determined to be
invalid, a participating ADMD SHOULD apply their own seal because failed, and marked with an ARC set bearing the "cv=fail" indication,
this can help in analysis of breakage points in the chain. each participating ADMD SHOULD apply their own seal.
6.2. Relationship between DKIM Signatures and ARC Headers 6.2. Relationship between DKIM Signatures and ARC Headers
ARC-aware DKIM signers do not DKIM-sign any ARC header fields. ARC-aware DKIM signers do not DKIM-sign any ARC header fields.
6.3. Validating the ARC Set of Header Fields 6.3. Validating the ARC Set of Header Fields
Determining the validity of a chain of ARC sets is defined above in Determining the validity of a chain of ARC sets is defined above in
Section 5.1.1.5. Validation failures MUST be indicated with a "cv=" Section 5.1.1.5. Validation failures MUST be indicated with a "cv="
tag value of 'fail' when attaching a subsequent ARC-Seal header tag value of 'fail' when attaching a subsequent ARC-Seal header
skipping to change at page 15, line 50 skipping to change at page 16, line 7
participating intermediaries that result in a valid chain of ARC- participating intermediaries that result in a valid chain of ARC-
related header fields. The value of such a well-formed, valid chain related header fields. The value of such a well-formed, valid chain
needs to be interpreted with care since malicious content can be needs to be interpreted with care since malicious content can be
easily introduced by otherwise well-intended senders through machine easily introduced by otherwise well-intended senders through machine
or account compromises. All normal content-based analysis still or account compromises. All normal content-based analysis still
needs to be performed on any messages bearing a valid chain of ARC needs to be performed on any messages bearing a valid chain of ARC
header sets. header sets.
6.4.2. Responding to ARC Validity Violations 6.4.2. Responding to ARC Validity Violations
If a receiver determines that the ARC set of header fields has is If a receiver determines that the ARC chain has failed, the receiver
invalid, the receiver MAY signal the breakage through the extended MAY signal the breakage through the extended SMTP response code 5.7.7
SMTP response code 5.7.7 [RFC3463] "message integrity failure" [RFC3463] "message integrity failure" [ENHANCED-STATUS] and
[ENHANCED-STATUS] and corresponding SMTP response code. corresponding SMTP response code.
6.4.3. Recording the Results of ARC Evaluation 6.4.3. Recording the Results of ARC Evaluation
Receivers MAY add an "arc=pass" or "arc=fail" method annotation into Receivers MAY add an "arc=pass" or "arc=fail" method annotation into
a locally-affixed Authentication-Results [RFC7601] header field. a locally-affixed Authentication-Results [RFC7601] header field.
6.4.4. Output Data Points from ARC Evaluation 6.4.4. Output Data Points from ARC Evaluation
The evaluation of a series of ARC sets results in the following data The evaluation of a series of ARC sets results in the following data
which MAY be used to inform local-policy decisions: which MAY be used to inform local-policy decisions:
o A list of the "d=" domains found in the validated (all) ARC-Seal o A list of the "d=" domains found in the validated (all) ARC-Seal
header fields; header 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)
6.4.5. Reporting ARC Effects for DMARC Local Policy 6.4.5. Reporting ARC Effects for DMARC Local Policy - Interim
[[ Discussion on the IETF DMARC-WG list has indicated some interest
in more substantial reporting for analytic purposes. To support that
effort, the following guidance is provided only as an interim,
minimal data set. A more complete reporting construct will be
specified in a related spec - TBD. ]]
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 is augmented by adding a reporting of ARC-informed decisions is augmented by adding a
local_policy comment explanation as follows: local_policy comment explanation as follows:
<policy_evaluated> <policy_evaluated>
<disposition>delivered</disposition> <disposition>delivered</disposition>
<dkim>fail</dkim> <dkim>fail</dkim>
<spf>fail</spf> <spf>fail</spf>
skipping to change at page 23, line 6 skipping to change at page 23, line 27
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, DOI 10.17487/RFC3463, January 2003, RFC 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", 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/RFC5234, January 2008, DOI 10.17487/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,
 End of changes. 22 change blocks. 
33 lines changed or deleted 39 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/