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/