draft-ietf-dmarc-arc-protocol-02.txt   draft-ietf-dmarc-arc-protocol-03.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: September 16, 2017 Google Expires: October 30, 2017 Google
S. Jones, Ed. S. Jones, Ed.
TDP TDP
March 15, 2017 April 28, 2017
Authenticated Received Chain (ARC) Protocol Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-02 draft-ietf-dmarc-arc-protocol-03
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 September 16, 2017. This Internet-Draft will expire on October 30, 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 4, line 8 skipping to change at page 4, line 8
defines an Authenticated Received Chain (ARC). ARC addresses the defines an Authenticated Received Chain (ARC). ARC addresses the
problems with the untrustworthiness of the standard Received header problems with the untrustworthiness of the standard Received header
field sequence. Through the information tracked in the ARC series of field sequence. Through the information tracked in the ARC series of
headers, receivers can develop a more nuanced interpretation to guide headers, receivers can develop a more nuanced interpretation to guide
any local policies related to messages that arrive with broken domain any 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) intermediary assuming all ADministrative Management Domain (ADMD) ([RFC5598],
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
transmitted from the evaluating agent to a consuming agent that uses transmitted from the evaluating agent to a consuming agent that uses
the information. On its own, A-R is believable only within a trust the information. On its own, A-R is believable only within a trust
domain. ARC provides a protection mechanism for the data, permiting domain. ARC provides a protection mechanism for the data, permiting
the communication to cross trust domain boundaries. the communication to cross trust domain boundaries.
2. Requirements 2. Requirements
skipping to change at page 11, line 38 skipping to change at page 11, line 38
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
ARC-Authentication-Results is a direct copy of the Authentication- ARC-Authentication-Results is a copy of the Authentication-Results
Results header field [RFC7601] created for archival purposes by the header field [RFC7601] value with the corresponding ARC-set instance
each MTA outside of the trust boundary of the originating system ("i=") tag value prefixed to the Authentication-Results value string.
which is contributing to the chain of ARC header fields. The Since Authentication-Results headers are frequently deleted from a
corresponding instance ("i=") tag value MUST be prefixed to the message's header list, the AAR is created for archival purposes by
Authentication-Results. each ARC-participating ADMD outside of the trust boundary of the
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).
The value of the header field (after removing comments) consists of The value of the header field (after removing comments) consists of
an instance identifier, an authentication identifier, and then a an instance identifier, an authentication identifier, and then a
series of statements and supporting data, as described in [RFC7601]. series of statements and supporting data, as described in [RFC7601].
The header field can appear multiple times in a single message but The header field can appear multiple times in a single message but
each instance MUST have a unique "i=" value. each instance MUST have a unique "i=" value.
skipping to change at page 23, line 6 skipping to change at page 23, line 6
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, DOI 10.17487/RFC1345, June 1992, RFC 1345, DOI 10.17487/RFC1345, June 1992,
<http://www.rfc-editor.org/info/rfc1345>. <http://www.rfc-editor.org/info/rfc1345>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
<http://www.rfc-editor.org/info/rfc2142>. <http://www.rfc-editor.org/info/rfc2142>.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
<http://www.rfc-editor.org/info/rfc2606>. <http://www.rfc-editor.org/info/rfc2606>.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
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", BCP 26, 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, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234,
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,
<http://www.rfc-editor.org/info/rfc5321>. <http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <http://www.rfc-editor.org/info/rfc5322>.
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", RFC 5585, DOI Identified Mail (DKIM) Service Overview", RFC 5585,
10.17487/RFC5585, July 2009, DOI 10.17487/RFC5585, July 2009,
<http://www.rfc-editor.org/info/rfc5585>. <http://www.rfc-editor.org/info/rfc5585>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
10.17487/RFC5598, July 2009, DOI 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>. <http://www.rfc-editor.org/info/rfc5598>.
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
"DomainKeys Identified Mail (DKIM) Development, "DomainKeys Identified Mail (DKIM) Development,
Deployment, and Operations", RFC 5863, DOI 10.17487/ Deployment, and Operations", RFC 5863,
RFC5863, May 2010, DOI 10.17487/RFC5863, May 2010,
<http://www.rfc-editor.org/info/rfc5863>. <http://www.rfc-editor.org/info/rfc5863>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>. <http://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <http://www.rfc-editor.org/info/rfc6377>. September 2011, <http://www.rfc-editor.org/info/rfc6377>.
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
(DKIM) for Failure Reporting", RFC 6651, DOI 10.17487/ (DKIM) for Failure Reporting", RFC 6651,
RFC6651, June 2012, DOI 10.17487/RFC6651, June 2012,
<http://www.rfc-editor.org/info/rfc6651>. <http://www.rfc-editor.org/info/rfc6651>.
[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,
<http://www.rfc-editor.org/info/rfc7208>. <http://www.rfc-editor.org/info/rfc7208>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating [RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601, DOI 10.17487/ Message Authentication Status", RFC 7601,
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-05)", June 2016, <https://tools.ietf.org/html/draft-
ietf-dmarc-arc-protocol-00>. ietf-dmarc-arc-protocol-00>.
skipping to change at page 25, line 18 skipping to change at page 25, line 18
Indirect Email Flows", June 2016, Indirect Email Flows", June 2016,
<https://tools.ietf.org/html/draft-ietf-dmarc- <https://tools.ietf.org/html/draft-ietf-dmarc-
interoperability-17>. 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, DOI Code: The Implementation Status Section", RFC 6982,
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>.
11.3. URIs 11.3. URIs
[1] mailto:arc-discuss@dmarc.org [1] mailto:arc-discuss@dmarc.org
 End of changes. 16 change blocks. 
32 lines changed or deleted 33 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/