draft-ietf-dmarc-arc-protocol-17.txt   draft-ietf-dmarc-arc-protocol-18.txt 
DMARC Working Group K. Andersen DMARC Working Group K. Andersen
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Experimental B. Long, Ed. Intended status: Experimental B. Long, Ed.
Expires: April 4, 2019 Google Expires: April 5, 2019 Google
S. Blank, Ed. S. Blank, Ed.
Valimail Valimail
M. Kucherawy, Ed. M. Kucherawy, Ed.
TDP TDP
October 1, 2018 October 2, 2018
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-17 draft-ietf-dmarc-arc-protocol-18
Abstract Abstract
The Authenticated Received Chain (ARC) protocol provides an The Authenticated Received Chain (ARC) protocol provides an
authenticated "chain of custody" for a message, allowing each entity authenticated "chain of custody" for a message, allowing each entity
that handles the message to see what entities handled it before, and that handles the message to see what entities handled it before, and
to see what the message's authentication assessment was at each step to see what the message's authentication assessment was at each step
in the handling. in the handling.
ARC allows Internet Mail Handlers to attach assertions of message ARC allows Internet Mail Handlers to attach assertions of message
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2019. This Internet-Draft will expire on April 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 18 skipping to change at page 4, line 18
12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.14. Halon MTA . . . . . . . . . . . . . . . . . . . . . . . 32 12.14. Halon MTA . . . . . . . . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . 34
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Appendix A - Design Requirements . . . . . . . . . . 36 Appendix A. Appendix A - Design Requirements . . . . . . . . . . 36
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 36 A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 36
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 36 A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 36 Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 36
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 37 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 36
Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 37 Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The utility of widely deployed email authentication technologies such The utility of widely deployed email authentication technologies such
as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
by intermediate handlers. This impact is thoroughly documented in by intermediate handlers. This impact is thoroughly documented in
the defining documents for SPF and DKIM and further discussed in the defining documents for SPF and DKIM and further discussed in
skipping to change at page 7, line 29 skipping to change at page 7, line 29
3.3. Internet Mail Handlers / Intermediaries 3.3. Internet Mail Handlers / Intermediaries
Internet Mail Handlers process and deliver messages across the Internet Mail Handlers process and deliver messages across the
Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as
defined in [RFC5598]. defined in [RFC5598].
Throughout this document the term "intermediaries" refers to the both Throughout this document the term "intermediaries" refers to the both
regular MTAs as well as delivery/reposting agents such as mailing regular MTAs as well as delivery/reposting agents such as mailing
lists covered within the scope of [RFC5598]'s transit services. lists covered within the scope of [RFC5598]'s transit services.
"Intermediaries" and "Internet Mail Handlers" are used synonomously "Intermediaries" and "Internet Mail Handlers" are used synonymously
throughout this document. throughout this document.
3.4. Authentication Assessment 3.4. Authentication Assessment
The Authentication Assessment which is affixed to a message as part The Authentication Assessment which is affixed to a message as part
of each ARC Set consists of the "authres-payload" [I-D-7601bis]. For of each ARC Set consists of the "authres-payload" [I-D-7601bis]. For
the integrity of an ARC Set, the Authentication Assessment only needs the integrity of an ARC Set, the Authentication Assessment only needs
to be properly encapsulated within the ARC Set as defined below to be properly encapsulated within the ARC Set as defined below
Section 4.1. The accuracy or syntax of the authres-payload field Section 4.1. The accuracy or syntax of the authres-payload field
does not affect the validity of the ARC chain itself. does not affect the validity of the ARC chain itself.
skipping to change at page 13, line 31 skipping to change at page 13, line 31
processing step is called the "Chain Validation Status". Chain processing step is called the "Chain Validation Status". Chain
Validation Status information is communicated in several ways: Validation Status information is communicated in several ways:
o the AS header field in the "cv" tag, and o the AS header field in the "cv" tag, and
o as part of Authentication-Results and AAR header field(s). o as part of Authentication-Results and AAR header field(s).
Chain Validation Status has one of three possible values: Chain Validation Status has one of three possible values:
o none: There was no Authenticated Received Chain on the message o none: There was no Authenticated Received Chain on the message
when it arrived for validation. Typically this occurs when a when it arrived for validation. Typically, this occurs when a
message is received directly from a message's original Message message is received directly from a message's original Message
Transfer Agent (MTA) or Message Submission Agent (MSA), or from an Transfer Agent (MTA) or Message Submission Agent (MSA), or from an
upstream Internet Mail Handler that is not participating in ARC upstream Internet Mail Handler that is not participating in ARC
handling. handling.
o fail: The message contains an Authenticated Received Chain whose o fail: The message contains an Authenticated Received Chain whose
validation failed. validation failed.
o pass: The message contains an Authenticated Received Chain whose o pass: The message contains an Authenticated Received Chain whose
validation succeeded. validation succeeded.
skipping to change at page 24, line 12 skipping to change at page 24, line 12
Authentication Parameters registry with one new authentication method Authentication Parameters registry with one new authentication method
and several status codes. and several status codes.
10.1. Email Authentication Results Names Registry Update 10.1. Email Authentication Results Names Registry Update
This draft adds one Auth Method with three Codes to the IANA "Email This draft adds one Auth Method with three Codes to the IANA "Email
Authentication Result Names" registry: Authentication Result Names" registry:
o Auth Method : arc o Auth Method : arc
Code: "none", "pass", "fail" Code: "none", "pass", "fail"
Specification: [I-D.ARC] 2.2 Specification: this document 2.2
Status: active Status: active
10.2. Email Authentication Methods Registry Update 10.2. Email Authentication Methods Registry Update
This draft adds several new items to the Email Authentication Methods This draft adds several new items to the Email Authentication Methods
registry, most recently defined in [I-D-7601bis]: registry, most recently defined in [I-D-7601bis]:
o Method: arc o Method: arc
Definition: [I-D.ARC] Definition: this document
ptype: smtp ptype: smtp
Property: client-ip Property: client-ip
Value: IP address of originating SMTP connection Value: IP address of originating SMTP connection
Status: active Status: active
Version: 1 Version: 1
o Method: arc o Method: arc
Definition: [I-D.ARC] Definition: this document
ptype: header ptype: header
Property: oldest-pass Property: oldest-pass
Value: The instance id of the oldest validating AMS, or 0 if they Value: The instance id of the oldest validating AMS, or 0 if they
all pass (see Section 5.2) all pass (see Section 5.2)
Status: active Status: active
Version: 1 Version: 1
o Method: dkim o Method: dkim
Definition: [I-D-7601bis] Definition: [I-D-7601bis]
ptype: header ptype: header
skipping to change at page 25, line 5 skipping to change at page 25, line 5
10.3. Definitions of the ARC header fields 10.3. Definitions of the ARC header fields
This specification adds three new header fields to the "Permanent This specification adds three new header fields to the "Permanent
Message Header Field Registry", as follows: Message Header Field Registry", as follows:
o Header field name: ARC-Seal o Header field name: ARC-Seal
Applicable protocol: mail Applicable protocol: mail
Status: draft Status: draft
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [I-D.ARC] Specification document(s): this document
Related information: [RFC6376] Related information: [RFC6376]
o Header field name: ARC-Message-Signature o Header field name: ARC-Message-Signature
Applicable protocol: mail Applicable protocol: mail
Status: draft Status: draft
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [I-D.ARC] Specification document(s): this document
Related information: [RFC6376] Related information: [RFC6376]
o Header field name: ARC-Authentication-Results o Header field name: ARC-Authentication-Results
Applicable protocol: mail Applicable protocol: mail
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [I-D.ARC] Specification document(s): this document
Related information: [I-D-7601bis] Related information: [I-D-7601bis]
10.4. New Enhanced Status Code - ARC Validation 10.4. New Enhanced Status Code - ARC Validation
o Code: X.7.29 Sample Text: ARC validation failure Associated basic The following value should be added to the [ENHANCED-STATUS]
status code: 550 Description: This status code may be returned registry, as follows:
when a message fails multiple authentication checks, including ARC
validation Reference: [I-D.ARC] Submitter: K. Andersen Change o Code: X.7.29
controller: IESG Sample Text: ARC validation failure
Associated basic status code: 550
Description: This status code may be returned when a message fails
multiple authentication checks, including ARC validation
Reference: this document
Submitter: K. Andersen
Change controller: IESG
11. Experimental Considerations 11. Experimental Considerations
The ARC protocol is designed to address common interoperability The ARC protocol is designed to address common interoperability
issues introduced by intermediate message handlers. Interoperability issues introduced by intermediate message handlers. Interoperability
issues are described in [RFC6377] and [RFC7960]. issues are described in [RFC6377] and [RFC7960].
As the ARC protocol is implemented by Internet Mail Handlers over As the ARC protocol is implemented by Internet Mail Handlers over
time, the following should be evaluated in order to determine the time, the following should be evaluated in order to determine the
success of the protocol in accomplishing the intended benefits. success of the protocol in accomplishing the intended benefits.
skipping to change at page 27, line 7 skipping to change at page 27, line 10
Longer Authenticated Received Chains will require more queries to Longer Authenticated Received Chains will require more queries to
retrieve the keys for validating the chain. While this is not retrieve the keys for validating the chain. While this is not
believed to be a security issue (see Section 9.2), it is unclear how believed to be a security issue (see Section 9.2), it is unclear how
much overhead will truly be added. This is similar to some of the much overhead will truly be added. This is similar to some of the
initial processing and query load concerns which were debated at the initial processing and query load concerns which were debated at the
time of the DKIM specification development. time of the DKIM specification development.
Data should be collected to better understand usable length and Data should be collected to better understand usable length and
distribution of lengths found in valid Authenticated Received Chains distribution of lengths found in valid Authenticated Received Chains
along with the the DNS impact of processing Authenticated Received along with the DNS impact of processing Authenticated Received
Chains. Chains.
An effective operational maximum will have to be developed through An effective operational maximum will have to be developed through
deployment experience in the field. deployment experience in the field.
11.3.4. What Trace Information is Valuable 11.3.4. What Trace Information is Valuable
There are several edge cases where the information in the AAR can There are several edge cases where the information in the AAR can
make the difference between message delivery or rejection. For make the difference between message delivery or rejection. For
example, if there is a well known mailing list that seals with ARC example, if there is a well known mailing list that seals with ARC
skipping to change at page 31, line 24 skipping to change at page 31, line 24
o 2017-12-15: v0.50 released with full test set passing for ARC o 2017-12-15: v0.50 released with full test set passing for ARC
Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/ Contact Info: http://search.cpan.org/~mbradshaw/Mail-DKIM-0.50/
12.9. PERL Mail::Milter::Authentication module 12.9. PERL Mail::Milter::Authentication module
Organization: FastMail Organization: FastMail
Description: Email domain authentication milter, uses MAIL::DKIM (see Description: Email domain authentication milter, uses MAIL::DKIM (see
above) above)
Status of Operation: Intial validation completed during IETF99 Status of Operation: Initial validation completed during IETF99
hackathon with some follow-on work during the week hackathon with some follow-on work during the week
Coverage: Built to support [ARC-DRAFT-14] Coverage: Built to support [ARC-DRAFT-14]
Licensing: Open Source Licensing: Open Source
Implementation Notes: Implementation Notes:
o 2017-07-15: Validation functionality which interoperates with o 2017-07-15: Validation functionality which interoperates with
Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99, Gmail, AOL, dkimpy was demonstrated; later in the week of IETF99,
the signing functionality was reported to be working the signing functionality was reported to be working
o 2017-07-20: ARC functionality has not yet been pushed back to the o 2017-07-20: ARC functionality has not yet been pushed back to the
skipping to change at page 32, line 9 skipping to change at page 32, line 9
o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/ o 2018-01-05: Tracked as https://github.com/sympa-community/sympa/
issues/153 issues/153
Contact Info: https://github.com/sympa-community Contact Info: https://github.com/sympa-community
12.11. Oracle Messaging Server 12.11. Oracle Messaging Server
Organization: Oracle Organization: Oracle
Description: Description:
Status of Operation: Intial development work during IETF99 hackathon. Status of Operation: Initial development work during IETF99
Framework code is complete, crypto functionality requires integration hackathon. Framework code is complete, crypto functionality requires
with libsodium integration with libsodium
Coverage: Work in progress Coverage: Work in progress
Licensing: Unknown Licensing: Unknown
Implementation Notes: Implementation Notes:
o 2018-03: Protocol handling components are completed, but crypto is o 2018-03: Protocol handling components are completed, but crypto is
not yet functional. not yet functional.
Contact Info: Chris Newman, Oracle Contact Info: Chris Newman, Oracle
12.12. MessageSystems Momentum and PowerMTA platforms 12.12. MessageSystems Momentum and PowerMTA platforms
skipping to change at page 34, line 9 skipping to change at page 34, line 9
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208, Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014, DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>. <https://www.rfc-editor.org/info/rfc7208>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601,
DOI 10.17487/RFC7601, August 2015,
<https://www.rfc-editor.org/info/rfc7601>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[ARC-DRAFT-05] [ARC-DRAFT-05]
Andersen, K., "Authenticated Received Chain (ARC) Protocol Andersen, K., "Authenticated Received Chain (ARC) Protocol
(I-D-05)", n.d., <https://tools.ietf.org/html/ (I-D-05)", n.d., <https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-05>. draft-ietf-dmarc-arc-protocol-05>.
 End of changes. 18 change blocks. 
28 lines changed or deleted 29 lines changed or added

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