draft-ietf-dmarc-arc-protocol-03.txt		draft-ietf-dmarc-arc-protocol-04.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: October 30, 2017 Google		Expires: December 22, 2017 Google
	S. Jones, Ed.		S. Jones, Ed.
	TDP		TDP
	April 28, 2017		June 20, 2017
	Authenticated Received Chain (ARC) Protocol		Authenticated Received Chain (ARC) Protocol
	draft-ietf-dmarc-arc-protocol-03		draft-ietf-dmarc-arc-protocol-04
	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 October 30, 2017.		This Internet-Draft will expire on December 22, 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 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 . . . . . . . . . . . . . . . 14		5.3. Key Management and Binding . . . . . . . . . . . . . . . 13
	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 . . . . . . . . . . . . . . . . . 15		5.4.4. Obsolescence Period . . . . . . . . . . . . . . . . . 14
	6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	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. Responding to ARC Validity Violations . . . . . . . . 15
	6.4.3. Recording the Results of ARC Evaluation . . . . . . . 16		6.4.3. Recording the Results of ARC Evaluation . . . . . . . 16
	6.4.4. Output Data Points from ARC Evaluation . . . . . . . 16		6.4.4. Output Data Points from ARC Evaluation . . . . . . . 16
	6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 16		6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 16
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	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 . . . . . . . . . . 17
	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 . . . . . . 18
	9.2. AOL test reflector and internal tagging . . . . . . . . . 19		9.2. AOL test reflector and internal tagging . . . . . . . . . 19
	9.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 20		9.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 20		9.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 21		9.5. Mailman addition . . . . . . . . . . . . . . . . . . . . 20
	9.6. Copernica/MailerQ web-based validation . . . . . . . . . 21		9.6. Copernica/MailerQ web-based validation . . . . . . . . . 21
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 22		10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	10.1. Message Content Suspicion . . . . . . . . . . . . . . . 22		10.1. Message Content Suspicion . . . . . . . . . . . . . . . 22
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	11.1. Normative References . . . . . . . . . . . . . . . . . . 22		11.1. Normative References . . . . . . . . . . . . . . . . . . 22
	11.2. Informative References . . . . . . . . . . . . . . . . . 24		11.2. Informative References . . . . . . . . . . . . . . . . . 24
	11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25		11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	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) . . . . . . . . . . . . . 25
	A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 25		A.1. Example 1: Simple mailing list . . . . . . . . . . . . . 25
	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: . . . . . 25
	A.1.2. Message is then received at example.org . . . . . . . 26		A.1.2. Message is then received at example.org . . . . . . . 26
	skipping to change at page 3, line 43 ¶		skipping to change at page 3, line 43 ¶
	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
	ultimate receiver system need to preserve the validity of the DKIM		ultimate receiver system need to preserve the validity of the DKIM
	signature; however, there are common legitimate email practices which		signature; however, there are common legitimate email practices which
	break the DKIM validation ([DMARC-INTEROP]). This specification		break the DKIM validation ([RFC7960]). This specification defines an
	defines an Authenticated Received Chain (ARC). ARC addresses the		Authenticated Received Chain (ARC). ARC addresses the problems with
	problems with the untrustworthiness of the standard Received header		the untrustworthiness of the standard Received header field sequence.
	field sequence. Through the information tracked in the ARC series of		Through the information tracked in the ARC series of headers,
	headers, receivers can develop a more nuanced interpretation to guide		receivers can develop a more nuanced interpretation to guide any
	any local policies related to messages that arrive with broken domain		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) ([RFC5598],		assuming all ADministrative Management Domain (ADMD) ([RFC5598],
	section 2.2) intermediary 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
	skipping to change at page 10, line 36 ¶		skipping to change at page 10, line 36 ¶
	}		}
	}		}
	}		}
	return "pass"		return "pass"
	}		}
	5.1.2. ARC-Message-Signature		5.1.2. ARC-Message-Signature
	The ARC-Message-Signature header field is a special variant of a		The ARC-Message-Signature header field is a special variant of a
	DKIM-Signature [RFC6376], using only the relaxed header		DKIM-Signature [RFC6376].
	canonicalization rules specified in [RFC6376].
	The ARC-Message-Signature header field can appear multiple times in a		The ARC-Message-Signature header field can appear multiple times in a
	single message but each instance MUST have a unique "i=" value.		single message but each instance MUST have a unique "i=" value.
	5.1.2.1. Differences between DKIM-Signature and ARC-Message-Signature		5.1.2.1. Differences between DKIM-Signature and ARC-Message-Signature
	5.1.2.1.1. Header Fields Eligible For ARC-Message-Signature Inclusion		5.1.2.1.1. Header Fields Eligible For ARC-Message-Signature Inclusion
	Participants may include any other header fields within the scope of		Participants may include any other header fields within the scope of
	the ARC-Message-Signature signature except that they MUST NOT include		the ARC-Message-Signature signature except that they MUST NOT include
	skipping to change at page 24, line 40 ¶		skipping to change at page 24, line 20 ¶
	[RFC7601] Kucherawy, M., "Message Header Field for Indicating		[RFC7601] Kucherawy, M., "Message Header Field for Indicating
	Message Authentication Status", RFC 7601,		Message Authentication Status", RFC 7601,
	DOI 10.17487/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-03)", April 2017, <https://tools.ietf.org/html/draft-
	ietf-dmarc-arc-protocol-00>.		ietf-dmarc-arc-protocol-03>.
	[ARC-TEST]		[ARC-TEST]
	Blank, S., "ARC Test Suite", January 2017,		Blank, S., "ARC Test Suite", January 2017,
	<https://github.com/ValiMail/arc_test_suite>.		<https://github.com/ValiMail/arc_test_suite>.
	[ARC-USAGE]		[ARC-USAGE]
	Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,		Jones, S., Adams, T., Rae-Grant, J., and K. Andersen,
	"Recommended Usage of the ARC Headers", December 2017,		"Recommended Usage of the ARC Headers", December 2017,
	<https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-		<https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-
	01>.		01>.
	[DMARC-INTEROP]
	Martin, F., Lear, E., Draegen, T., Zwicky, E., and K.
	Andersen, "Interoperability Issues Between DMARC and
	Indirect Email Flows", June 2016,
	<https://tools.ietf.org/html/draft-ietf-dmarc-
	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,		Code: The Implementation Status Section", RFC 6982,
	DOI 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>.
			[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
			E., Ed., and K. Andersen, Ed., "Interoperability Issues
			between Domain-based Message Authentication, Reporting,
			and Conformance (DMARC) and Indirect Email Flows",
			RFC 7960, DOI 10.17487/RFC7960, September 2016,
			<http://www.rfc-editor.org/info/rfc7960>.
	11.3. URIs		11.3. URIs
	[1] mailto:arc-discuss@dmarc.org		[1] mailto:arc-discuss@dmarc.org
	[2] mailto:arc-discuss@dmarc.org		[2] mailto:arc-discuss@dmarc.org
	[3] mailto:arc-discuss@dmarc.org		[3] mailto:arc-discuss@dmarc.org
	[4] mailto:dmarc@ietf.org		[4] mailto:dmarc@ietf.org
End of changes. 17 change blocks.
	31 lines changed or deleted		30 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/