draft-ietf-dmarc-arc-protocol-03.txt   draft-ietf-dmarc-arc-protocol-04.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: October 30, 2017 Google Expires: December 22, 2017 Google
S. Jones, Ed. S. Jones, Ed.
TDP TDP
April 28, 2017 June 20, 2017
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-03 draft-ietf-dmarc-arc-protocol-04
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 October 30, 2017. This Internet-Draft will expire on December 22, 2017.
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 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . 10 5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 10
5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 11 5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 11
5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 12 5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 12
5.2.1. Handling Minor Violations in the ARC Sets . . . . . . 13 5.2.1. Handling Minor Violations in the ARC Sets . . . . . . 13
5.2.2. Handling Major Violations in the ARC Sets . . . . . . 13 5.2.2. Handling Major Violations in the ARC Sets . . . . . . 13
5.3. Key Management and Binding . . . . . . . . . . . . . . . 14 5.3. Key Management and Binding . . . . . . . . . . . . . . . 13
5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 14 5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Supporting Alternate Signing Algorithms . . . . . . . . . 14 5.4. Supporting Alternate Signing Algorithms . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . 15 5.4.4. Obsolescence Period . . . . . . . . . . . . . . . . . 14
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . 16 6.4.2. Responding to ARC Validity Violations . . . . . . . . 15
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 . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . 19 9.1. GMail test reflector and incoming validation . . . . . . 18
9.2. AOL test reflector and internal tagging . . . . . . . . . 19 9.2. AOL test reflector and internal tagging . . . . . . . . . 19
9.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 21 9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 20
9.6. Copernica/MailerQ web-based validation . . . . . . . . . 21 9.6. Copernica/MailerQ web-based validation . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
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 3, line 43 skipping to change at page 3, line 43
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
ultimate receiver system need to preserve the validity of the DKIM ultimate receiver system need to preserve the validity of the DKIM
signature; however, there are common legitimate email practices which signature; however, there are common legitimate email practices which
break the DKIM validation ([DMARC-INTEROP]). This specification break the DKIM validation ([RFC7960]). This specification defines an
defines an Authenticated Received Chain (ARC). ARC addresses the Authenticated Received Chain (ARC). ARC addresses the problems with
problems with the untrustworthiness of the standard Received header the untrustworthiness of the standard Received header field sequence.
field sequence. Through the information tracked in the ARC series of Through the information tracked in the ARC series of headers,
headers, receivers can develop a more nuanced interpretation to guide receivers can develop a more nuanced interpretation to guide any
any local policies related to messages that arrive with broken domain local policies related to messages that arrive with broken domain
authentication (DMARC). authentication (DMARC).
Forgery of the Received header fields is a common tactic used by bad Forgery of the Received header fields is a common tactic used by bad
actors. One of the goals of this specification defines a comparable actors. One of the goals of this specification defines a comparable
set of trace header fields which can be relied upon by receivers, set of trace header fields which can be relied upon by receivers,
assuming all ADministrative Management Domain (ADMD) ([RFC5598], assuming all ADministrative Management Domain (ADMD) ([RFC5598],
section 2.2) intermediary handlers of a message participate in ARC. section 2.2) intermediary handlers of a message participate in ARC.
The Authentication-Results (A-R) mechanism [RFC7601] permits the The Authentication-Results (A-R) mechanism [RFC7601] permits the
output of an email authentication evaluation process to be output of an email authentication evaluation process to be
skipping to change at page 10, line 36 skipping to change at page 10, line 36
} }
} }
} }
return "pass" return "pass"
} }
5.1.2. ARC-Message-Signature 5.1.2. ARC-Message-Signature
The ARC-Message-Signature header field is a special variant of a The ARC-Message-Signature header field is a special variant of a
DKIM-Signature [RFC6376], using only the relaxed header DKIM-Signature [RFC6376].
canonicalization rules specified in [RFC6376].
The ARC-Message-Signature header field can appear multiple times in a The ARC-Message-Signature header field can appear multiple times in a
single message but each instance MUST have a unique "i=" value. single message but each instance MUST have a unique "i=" value.
5.1.2.1. Differences between DKIM-Signature and ARC-Message-Signature 5.1.2.1. Differences between DKIM-Signature and ARC-Message-Signature
5.1.2.1.1. Header Fields Eligible For ARC-Message-Signature Inclusion 5.1.2.1.1. Header Fields Eligible For ARC-Message-Signature Inclusion
Participants may include any other header fields within the scope of Participants may include any other header fields within the scope of
the ARC-Message-Signature signature except that they MUST NOT include the ARC-Message-Signature signature except that they MUST NOT include
skipping to change at page 24, line 40 skipping to change at page 24, line 20
[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,
<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-03)", April 2017, <https://tools.ietf.org/html/draft-
ietf-dmarc-arc-protocol-00>. ietf-dmarc-arc-protocol-03>.
[ARC-TEST] [ARC-TEST]
Blank, S., "ARC Test Suite", January 2017, Blank, S., "ARC Test Suite", January 2017,
<https://github.com/ValiMail/arc_test_suite>. <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", December 2017, "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-
01>. 01>.
[DMARC-INTEROP]
Martin, F., Lear, E., Draegen, T., Zwicky, E., and K.
Andersen, "Interoperability Issues Between DMARC and
Indirect Email Flows", June 2016,
<https://tools.ietf.org/html/draft-ietf-dmarc-
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 10.17487/RFC6982, July 2013, DOI 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>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016,
<http://www.rfc-editor.org/info/rfc7960>.
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:dmarc@ietf.org [4] mailto:dmarc@ietf.org
 End of changes. 17 change blocks. 
31 lines changed or deleted 30 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/