--- 1/draft-ietf-dmarc-arc-protocol-02.txt 2017-04-28 16:13:10.132357496 -0700 +++ 2/draft-ietf-dmarc-arc-protocol-03.txt 2017-04-28 16:13:10.208359326 -0700 @@ -1,21 +1,21 @@ DMARC Working Group K. Andersen Internet-Draft LinkedIn Intended status: Standards Track B. Long, Ed. -Expires: September 16, 2017 Google +Expires: October 30, 2017 Google S. Jones, Ed. TDP - March 15, 2017 + April 28, 2017 Authenticated Received Chain (ARC) Protocol - draft-ietf-dmarc-arc-protocol-02 + draft-ietf-dmarc-arc-protocol-03 Abstract Authenticated Received Chain (ARC) permits an organization which is creating or handling email to indicate its involvement with the handling process. It defines a set of cryptographically signed header fields in a manner analagous to that of DKIM. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Changes in the message that might break DKIM can be @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 16, 2017. + This Internet-Draft will expire on October 30, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -137,22 +137,22 @@ defines an Authenticated Received Chain (ARC). ARC addresses the problems with the untrustworthiness of the standard Received header field sequence. Through the information tracked in the ARC series of headers, receivers can develop a more nuanced interpretation to guide any local policies related to messages that arrive with broken domain authentication (DMARC). Forgery of the Received header fields is a common tactic used by bad actors. One of the goals of this specification defines a comparable set of trace header fields which can be relied upon by receivers, - assuming all ADministrative Management Domain (ADMD) intermediary - handlers of a message participate in ARC. + assuming all ADministrative Management Domain (ADMD) ([RFC5598], + section 2.2) intermediary handlers of a message participate in ARC. The Authentication-Results (A-R) mechanism [RFC7601] permits the output of an email authentication evaluation process to be transmitted from the evaluating agent to a consuming agent that uses the information. On its own, A-R is believable only within a trust domain. ARC provides a protection mechanism for the data, permiting the communication to cross trust domain boundaries. 2. Requirements @@ -486,26 +486,27 @@ As with DKIM-Signature and ARC-Seal header fields, the "b" tag of the ARC-Message-Signature is empty until the signature is actually computed, and only then is it added to the header field, before affixing the ARC-Message-Signature to the message. As with ARC-Seal and DKIM-Signature header fields, the order of header fields signed MUST be done in bottom-up order. 5.1.3. ARC-Authentication-Results - ARC-Authentication-Results is a direct copy of the Authentication- - Results header field [RFC7601] created for archival purposes by the - each MTA outside of the trust boundary of the originating system - which is contributing to the chain of ARC header fields. The - corresponding instance ("i=") tag value MUST be prefixed to the - Authentication-Results. + ARC-Authentication-Results is a copy of the Authentication-Results + header field [RFC7601] value with the corresponding ARC-set instance + ("i=") tag value prefixed to the Authentication-Results value string. + Since Authentication-Results headers are frequently deleted from a + message's header list, the AAR is created for archival purposes by + each ARC-participating ADMD outside of the trust boundary of the + originating system. The instance identifier MUST be separated from the rest of the Authentication-Results value contents with a semi-colon (';', 0x3b). The value of the header field (after removing comments) consists of an instance identifier, an authentication identifier, and then a series of statements and supporting data, as described in [RFC7601]. The header field can appear multiple times in a single message but each instance MUST have a unique "i=" value. @@ -1007,95 +1008,95 @@ 11. References 11.1. Normative References [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", RFC 1345, DOI 10.17487/RFC1345, June 1992, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, . [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, . - [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC - 3463, DOI 10.17487/RFC3463, January 2003, + [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", + RFC 3463, DOI 10.17487/RFC3463, January 2003, . [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686, September 2006, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ - RFC5234, January 2008, + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . - [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI - 10.17487/RFC5322, October 2008, + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, . [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys - Identified Mail (DKIM) Service Overview", RFC 5585, DOI - 10.17487/RFC5585, July 2009, + Identified Mail (DKIM) Service Overview", RFC 5585, + DOI 10.17487/RFC5585, July 2009, . - [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI - 10.17487/RFC5598, July 2009, + [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, + DOI 10.17487/RFC5598, July 2009, . [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, - Deployment, and Operations", RFC 5863, DOI 10.17487/ - RFC5863, May 2010, + Deployment, and Operations", RFC 5863, + DOI 10.17487/RFC5863, May 2010, . [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, September 2011, . [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail - (DKIM) for Failure Reporting", RFC 6651, DOI 10.17487/ - RFC6651, June 2012, + (DKIM) for Failure Reporting", RFC 6651, + DOI 10.17487/RFC6651, June 2012, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7601] Kucherawy, M., "Message Header Field for Indicating - Message Authentication Status", RFC 7601, DOI 10.17487/ - RFC7601, August 2015, + Message Authentication Status", RFC 7601, + DOI 10.17487/RFC7601, August 2015, . 11.2. Informative References [ARC-DRAFT] Andersen, K., Rae-Grant, J., Long, B., Adams, T., and S. Jones, "Authenticated Received Chain (ARC) Protocol (I-D-05)", June 2016, . @@ -1115,22 +1116,22 @@ Indirect Email Flows", June 2016, . [ENHANCED-STATUS] "IANA SMTP Enhanced Status Codes", n.d., . [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running - Code: The Implementation Status Section", RFC 6982, DOI - 10.17487/RFC6982, July 2013, + Code: The Implementation Status Section", RFC 6982, + DOI 10.17487/RFC6982, July 2013, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . 11.3. URIs [1] mailto:arc-discuss@dmarc.org