draft-ietf-dmarc-arc-protocol-05.txt   draft-ietf-dmarc-arc-protocol-06.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: January 1, 2018 Google Expires: January 19, 2018 Google
S. Jones, Ed. S. Jones, Ed.
TDP TDP
June 30, 2017 July 18, 2017
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-05 draft-ietf-dmarc-arc-protocol-06
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 January 1, 2018. This Internet-Draft will expire on January 19, 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 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 . . . . . . . . . . . . . . . 13 5.3. Key Management and Binding . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . 14 5.4.4. Obsolescence Period . . . . . . . . . . . . . . . . . 15
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
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. Marking and Sealing Invalid Chains . . . . . . . . . 16
6.4.3. Recording the Results of ARC Evaluation . . . . . . . 16 6.4.3. Responding to ARC Validity Violations . . . . . . . . 16
6.4.4. Output Data Points from ARC Evaluation . . . . . . . 16 6.4.4. Recording the Results of ARC Evaluation . . . . . . . 16
6.4.5. Reporting ARC Effects for DMARC Local Policy - 6.4.5. Output Data Points from ARC Evaluation . . . . . . . 16
6.4.6. Reporting ARC Effects for DMARC Local Policy -
Interim . . . . . . . . . . . . . . . . . . . . . . . 16 Interim . . . . . . . . . . . . . . . . . . . . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA 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 . . . . . . . . . . 18
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 . . . . . . 19
9.2. AOL test reflector and internal tagging . . . . . . . . . 19 9.2. AOL test reflector and internal tagging . . . . . . . . . 20
9.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 21 9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 21
9.6. Copernica/MailerQ web-based validation . . . . . . . . . 21 9.6. Copernica/MailerQ web-based validation . . . . . . . . . 22
9.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10.1. Message Content Suspicion . . . . . . . . . . . . . . . 22 10.1. Message Content Suspicion . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
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) . . . . . . . . . . . . . 26
A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 25 A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 26
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: . . . . . 26
A.1.2. Message is then received at example.org . . . . . . . 26 A.1.2. Message is then received at example.org . . . . . . . 27
A.1.3. Example 1: Message received by Recipient . . . . . . 28 A.1.3. Example 1: Message received by Recipient . . . . . . 29
A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 29 A.2. Example 2: Mailing list to forwarded mailbox . . . . . . 30
A.2.1. Here's the message as it exits the Origin: . . . . . 29 A.2.1. Here's the message as it exits the Origin: . . . . . 30
A.2.2. Message is then received at example.org . . . . . . . 30 A.2.2. Message is then received at example.org . . . . . . . 31
A.2.3. Example 2: Message received by Recipient . . . . . . 34 A.2.3. Example 2: Message received by Recipient . . . . . . 35
A.3. Example 3: Mailing list to forwarded mailbox with source 36 A.3. Example 3: Mailing list to forwarded mailbox with source 37
A.3.1. Here's the message as it exits the Origin: . . . . . 36 A.3.1. Here's the message as it exits the Origin: . . . . . 37
A.3.2. Message is then received at example.org . . . . . . . 37 A.3.2. Message is then received at example.org . . . . . . . 38
A.3.3. Example 3: Message received by Recipient . . . . . . 42 A.3.3. Example 3: Message received by Recipient . . . . . . 43
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 44 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 45
Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 45 Appendix C. Comments and Feedback . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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 11, line 36 skipping to change at page 11, line 36
As with DKIM-Signature and ARC-Seal header fields, the "b" tag of the As with DKIM-Signature and ARC-Seal header fields, the "b" tag of the
ARC-Message-Signature is empty until the signature is actually ARC-Message-Signature is empty until the signature is actually
computed, and only then is it added to the header field, before computed, and only then is it added to the header field, before
affixing the ARC-Message-Signature to the message. affixing the ARC-Message-Signature to the message.
As with ARC-Seal and DKIM-Signature header fields, the order of As with ARC-Seal and DKIM-Signature header fields, the order of
header fields signed MUST be done in bottom-up order. header fields signed MUST be done in bottom-up order.
5.1.3. ARC-Authentication-Results 5.1.3. ARC-Authentication-Results
[[ Note: The intent of the AAR header is to provide the necessary
information for meaningful DMARC reporting back to the originating
ADMD. As such, it needs to include additional information than the
user-focused Authentication-Results header [RFC7601] but the details
of that incremental information have not yet been fully determined.
]]
ARC-Authentication-Results is a copy of the Authentication-Results ARC-Authentication-Results is a copy of the Authentication-Results
header field [RFC7601] value with the corresponding ARC-set instance header field [RFC7601] value with the corresponding ARC-set instance
("i=") tag value prefixed to the Authentication-Results value string. ("i=") tag value prefixed to the Authentication-Results value string.
Since Authentication-Results headers are frequently deleted from a Since Authentication-Results headers are frequently deleted from a
message's header list, the AAR is created for archival purposes by message's header list, the AAR is created for archival purposes by
each ARC-participating ADMD outside of the trust boundary of the each ARC-participating ADMD outside of the trust boundary of the
originating system. originating system.
The instance identifier MUST be separated from the rest of the The instance identifier MUST be separated from the rest of the
Authentication-Results value contents with a semi-colon (';', 0x3b). Authentication-Results value contents with a semi-colon (';', 0x3b).
skipping to change at page 16, line 5 skipping to change at page 16, line 11
This specification is exclusively focused on well-behaved, This specification is exclusively focused on well-behaved,
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. Marking and Sealing Invalid Chains
The header fields signed by the AS header field b= value 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. (This is the same procedure
required for handling major/structural validity problems.)
6.4.3. 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.
6.4.3. Recording the Results of ARC Evaluation 6.4.4. 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.5. 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 - Interim 6.4.6. 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. ]]
[[ Note: 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. (see also the note at
Section 5.1.3) ]]
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>
<reason> <reason>
skipping to change at page 21, line 43 skipping to change at page 22, line 15
9.6. Copernica/MailerQ web-based validation 9.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] Coverage: Built to support [ARC-DRAFT]
Licensing: On-line usage only, Licensing: On-line usage only
Implementation Notes: Released 2016-10-24 Implementation Notes: Released 2016-10-24
Requires full message content to be pasted into a web form found at Requires full message content to be pasted into a web form found at
[http://arc.mailerq.com/] (warning - https is not supported). [http://arc.mailerq.com/] (warning - https is not supported).
An additional instance of an ARC signature can be added if one is 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.
Initial testing shows that results match the other implementations Initial testing shows that results match the other implementations
listed in this section. listed in this section.
Contact Info: [https://www.copernica.com/] Contact Info: [https://www.copernica.com/]
9.7. Rspamd
Organization: Rspamd community
Description: ARC signing and verification module
Status of Operation: Production, though deployment usage is unknown
Coverage: Built to support [ARC-DRAFT]
Licensing: Open source
Implementation Notes: Released with version 1.6.0 on 2017-06-12
Contact Info: [https://rspamd.com/doc/modules/arc.html] and
[https://github.com/vstakhov/rspamd]
10. Security Considerations 10. 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.
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.
Operators who receive a message bearing N ARC sets has to complete Operators who receive a message bearing N ARC sets has to complete
 End of changes. 21 change blocks. 
47 lines changed or deleted 81 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/