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/