draft-ietf-dmarc-psd-11.txt		draft-ietf-dmarc-psd-10.txt
	Network Working Group S. Kitterman		Network Working Group S. Kitterman
	Internet-Draft fTLD Registry Services		Internet-Draft fTLD Registry Services
	Intended status: Experimental January 1, 2021		Intended status: Experimental January 23, 2021
	Expires: July 5, 2021		Expires: July 27, 2021
	Experimental DMARC Extension For Public Suffix Domains		Experimental DMARC Extension For Public Suffix Domains
	draft-ietf-dmarc-psd-11		draft-ietf-dmarc-psd-10
	Abstract		Abstract
	Domain-based Message Authentication, Reporting, and Conformance		DMARC (Domain-based Message Authentication, Reporting, and
	(DMARC) permits a domain-controlling organization to express domain-		Conformance) is a scalable mechanism by which a mail-originating
	level policies and preferences for message validation, disposition,		organization can express domain-level policies and preferences for
	and reporting, which a mail-receiving organization can use to improve		message validation, disposition, and reporting, that a mail-receiving
	mail handling.		organization can use to improve mail handling. The design of DMARC
			presumes that domain names represent either nodes in the tree below
			which registrations occur, or nodes where registrations have
			occurred; it does not permit a domain name to have both of these
			properties simultaneously. Since its deployment in 2015, use of
			DMARC has shown a clear need for the ability to express policy for
			these domains as well.
	DMARC distinguishes the portion of a name that is a Public Suffix		Domains at which registrations can occur are referred to as Public
	Domain (PSD), below which organizational domain names are created.		Suffix Domains (PSDs). This document describes an extension to DMARC
	The basic DMARC capability allows organizational domains to specify		to enable DMARC functionality for PSDs.
	policies that apply to their subdomains, but it does not give that
	capability to PSDs. This document describes an extension to DMARC to
	fully enable DMARC functionality for PSDs.
	Some implementations of DMARC consider a PSD to be ineligible for		This document also seeks to address implementations that consider a
	DMARC enforcement. This specification addresses that case.		domain on a public Suffix list to be ineligible for DMARC
			enforcement.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 July 5, 2021.		This Internet-Draft will expire on July 27, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 2, line 34		skipping to change at page 2, line 34
	1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5		2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
	2.1. Conventions Used in This Document . . . . . . . . . . . . 5		2.1. Conventions Used in This Document . . . . . . . . . . . . 5
	2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5		2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5
	2.3. Organizational Domain . . . . . . . . . . . . . . . . . . 6		2.3. Organizational Domain . . . . . . . . . . . . . . . . . . 6
	2.4. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 6		2.4. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 6
	2.5. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 6		2.5. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 6
	2.6. PSO Controlled Domain Names . . . . . . . . . . . . . . . 6		2.6. PSO Controlled Domain Names . . . . . . . . . . . . . . . 6
	2.7. Non-existent Domains . . . . . . . . . . . . . . . . . . 6		2.7. Non-existent Domains . . . . . . . . . . . . . . . . . . 6
	3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 6		3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 6
	3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 6		3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Changes in Section 6.3 "General Record Format" . . . . . 7		3.2. Changes in Section 6.3 "General Record Format" . . . . . 7
	3.3. Changes in Section 6.5 "Domain Owner Actions" . . . . . . 7		3.3. Changes in Section 6.5 "Domain Owner Actions" . . . . . . 7
	3.4. Changes in Section 6.6.1 "Extract Author Domain" . . . . 7		3.4. Changes in Section 6.6.1 "Extract Author Domain" . . . . 7
	3.5. Changes in Section 6.6.3 "Policy Discovery" . . . . . . . 8		3.5. Changes in Section 6.6.3 "Policy Discovery" . . . . . . . 8
	3.6. Changes in Section 7 "DMARC Feedback" . . . . . . . . . . 8		3.6. Changes in Section 7 "DMARC Feedback" . . . . . . . . . . 8
	4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8		4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
	4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 8		4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 10		6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. PSD DMARC Privacy Concern Mitigation Experiment . . 12		Appendix A. PSD DMARC Privacy Concern Mitigation Experiment . . 12
	Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12		Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12
	B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 12		B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 12
	B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 12		B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 12
	B.3. DMARC PSD PSL Extension . . . . . . . . . . . . . . . . . 13		B.3. DMARC PSD PSL Extension . . . . . . . . . . . . . . . . . 13
	Appendix C. Implementations . . . . . . . . . . . . . . . . . . 13		Appendix C. Implementations . . . . . . . . . . . . . . . . . . 13
	C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 13		C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 13
	C.2. Zdkimfilter Module . . . . . . . . . . . . . . . . . . . 14		C.2. Zdkimfilter Module . . . . . . . . . . . . . . . . . . . 14
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	DMARC ([RFC7489]) provides a mechanism for publishing organizational		DMARC [RFC7489] provides a mechanism for publishing organizational
	policy information to email receivers. DMARC allows policy to be		policy information to email receivers. DMARC allows policy to be
	specified for both individual domains and for organizational domains		specified for both individual domains and for organizational domains
	and their sub-domains within a single organization.		and their sub-domains within a single organization.
	To determine the organizational domain for a message under		To determine the organizational domain for a message under
	evaluation, and thus where to look for a policy statement, DMARC		evaluation, and thus where to look for a policy statement, DMARC
	makes use of a Public Suffix List. The process for doing this can be		makes use of a Public Suffix List. The process for doing this can be
	found in Section 3.2 of the DMARC specification.		found in Section 3.2 of the DMARC specification.
	In the basic DMARC model, PSDs are not organizational domains and are		DMARC as specified presumes that domain names present in a PSL are
	thus not subject to DMARC processing. In DMARC, domains fall into		not organizational domains and thus not subject to DMARC processing;
	one of three categories: organizational domains, sub-domains of		domains are either organizational domains, sub-domains of
	organizational domains, or PSDs. A PSD can only publish DMARC policy		organizational domains, or listed on a PSL. For domains listed in a
	for itself, and not for any sub-domains under it. In some cases,		PSL, i.e., TLDs and domains that exist between TLDs and organization
	this limitation allows for the abuse of non-existent organizational-		level domains, policy can only be published for the exact domain. No
	level domains and hampers identification of domain abuse in email.		method is available for these domains to express policy or receive
			feedback reporting for sub-domains. This missing method allows for
			the abuse of non-existent organizational-level domains and prevents
			identification of domain abuse in email.
	This document specifies experimental updates to the DMARC and PSL		This document specifies experimental updates to the DMARC and PSL
	algorithm cited above, in an attempt to mitigate this abuse.		algorithm cited above, in an attempt to mitigate this abuse.
	1.1. Example		1.1. Example
	As an example, imagine a Top-Level Domain (TLD), ".example", that has		As an example, imagine a country code TLD (ccTLD) which has public
	public subdomains for government and commercial use (".gov.example"		subdomains for government and commercial use (".gov.example" and
	and ".com.example"). The maintainer of a list of such a PSD		".com.example"). A PSL whose maintainer is aware of this country's
	structure would include entries for both of these sub-domains,		domain structurewould include entries for both of these in the PSL,
	thereby indicating that they are PSDs, below which organizational		indicating that they are PSDs below which registrations can occur.
	domains can be registered. Suppose further that there exists a		Suppose further that there exists a domain "tax.gov.example",
	legitimate domain called "tax.gov.example", registered within		registered within ".gov.example", that is responsible for taxation in
	".gov.example".		this imagined country.
	However, by exploiting the typically unauthenticated nature of email,		However, by exploiting the typically unauthenticated nature of email,
	there are regular malicious campaigns to impersonate this		there are regular malicious campaigns to impersonate this
	organization that use similar-looking ("cousin") domains such as		organization that use similar-looking ("cousin") domains such as
	"t4x.gov.example". Such domains are not registered.		"t4x.gov.example". Such domains are not registered.
	Within the ".gov.example" public suffix, use of DMARC has been		Within the ".gov.example" public suffix, use of DMARC has been
	mandated, so "gov.example" publishes the following DMARC DNS record:		mandated, so "gov.example" publishes the following DMARC DNS record:
	_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject; "		_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject; "
	"rua=mailto:dmc@dmarc.svc.gov.example" )		"rua=mailto:dmc@dmarc.svc.gov.example" )
	This DMARC record provides policy and a reporting destination for		This DMARC record provides policy and a reporting destination for
	mail sent from @gov.example. Similarly, "tax.gov.example" will have		mail sent from @gov.example. However, due to DMARC's current method
	a DMARC record that specifies policy for mail sent from addresses		of discovering and applying policy at the organizational domain
	@tax.gov.example. However, due to DMARC's current method of		level, the non-existent organizational domain of @t4x.gov.example
	discovering and applying policy at the organizational domain level,		does not and cannot fall under a DMARC policy.
	the non-existent organizational domain of @t4x.gov.example does not
	and cannot fall under a DMARC policy.
	Defensively registering all variants of "tax" is obviously not a		Defensively registering all variants of "tax" is obviously not a
	scalable strategy. The intent of this specification, therefore, is		scalable strategy. The intent of this specification, therefore, is
	to enhance the DMARC algorithm by enabling an agent receiving such a		to enhance the DMARC algorithm by enabling an agent receiving such a
	message to be able to determine that a relevant policy is present at		message to be able to determine that a relevant policy is present at
	"gov.example", which is precluded by the current DMARC algorithm.		"gov.example", which is precluded by the current DMARC algorithm.
	1.2. Discussion		1.2. Discussion
	This document provides a simple extension to [RFC7489] to allow		This document provides a simple extension to DMARC [RFC7489] to allow
	operators of Public Suffix Domains (PSDs) to:		operators of Public Suffix Domains (PSDs) to:
	o Express policy at the level of the PSD that covers all		o Express policy at the level of the PSD that covers all
	organizational domains that do not explicitly publish DMARC		organizational domains that do not explicitly publish DMARC
	records		records
	o Extends the DMARC policy query functionality to detect and process		o Extends the DMARC policy query functionality to detect and process
	such a policy		such a policy
	o Describes receiver feedback for such policies		o Describes receiver feedback for such policies
	skipping to change at page 4, line 48		skipping to change at page 4, line 49
	This document also provides a new DMARC tag to indicate requested		This document also provides a new DMARC tag to indicate requested
	handling policy for non-existent subdommains. This is provided		handling policy for non-existent subdommains. This is provided
	specifically to support phased deployment of PSD DMARC, but is		specifically to support phased deployment of PSD DMARC, but is
	expected to be useful more generally. Undesired rejection risks for		expected to be useful more generally. Undesired rejection risks for
	mail purporting to be from domains that do not exist are		mail purporting to be from domains that do not exist are
	substantially lower than for those that do, so the operational risk		substantially lower than for those that do, so the operational risk
	of requesting harsh policy treatment (e.g. reject) is lower.		of requesting harsh policy treatment (e.g. reject) is lower.
	As an additional benefit, the PSD DMARC extension clarifies existing		As an additional benefit, the PSD DMARC extension clarifies existing
	requirements. Based on the requirements of [RFC7489], DMARC should		requirements. Based on the requirements of DMARC [RFC7489], DMARC
	function above the organizational level for exact domain matches		should function above the organizational level for exact domain
	(i.e. if a DMARC record were published for 'example', then mail from		matches (i.e. if a DMARC record were published for 'example', then
	example@example should be subject to DMARC processing). Testing had		mail from example@example should be subject to DMARC processing).
	revealed that this is not consistently applied in different
	implementations.		Testing had revealed that this is not consistently applied in
			different implementations.
	There are two types of Public Suffix Operators (PSOs) for which this		There are two types of Public Suffix Operators (PSOs) for which this
	extension would be useful and appropriate:		extension would be useful and appropriate:
	o Branded PSDs (e.g., ".google"): These domains are effectively		o Branded PSDs (e.g., ".google"): These domains are effectively
	Organizational Domains as discussed in [RFC7489]. They control		Organizational Domains as discussed in DMARC [RFC7489]. They
	all subdomains of the tree. These are effectively private		control all subdomains of the tree. These are effectively private
	domains, but listed in the Public Suffix List. They are treated		domains, but listed in the Public Suffix List. They are treated
	as Public for DMARC purposes. They require the same protections		as Public for DMARC purposes. They require the same protections
	as DMARC Organizational Domains, but are currently unable to		as DMARC Organizational Domains, but are currently unable to
	benefit from DMARC.		benefit from DMARC.
	o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):		o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
	Because existing Organizational Domains using this PSD have their		Because existing Organizational Domains using this PSD have their
	own DMARC policy, the applicability of this extension is for non-		own DMARC policy, the applicability of this extension is for non-
	existent domains. The extension allows the brand protection		existent domains. The extension allows the brand protection
	benefits of DMARC to extend to the entire PSD, including cousin		benefits of DMARC to extend to the entire PSD, including cousin
	domains of registered organizations.		domains of registered organizations.
	Due to the design of DMARC and the nature of the Internet email		Due to the design of DMARC and the nature of the Internet email
	architecture [RFC5598], there are interoperability issues associated		architecture [RFC5598], there are interoperability issues associated
	with DMARC deployment. These are discussed in Interoperability		with DMARC [RFC7489] deployment. These are discussed in
	Issues between DMARC and Indirect Email Flows [RFC7960]. These		Interoperability Issues between DMARC and Indirect Email Flows
	issues are not typically applicable to PSDs, since they (e.g., the		[RFC7960]. These issues are not typically applicable to PSDs, since
	".gov.example" used above) do not typically send mail.		they (e.g., the ".gov.example" used above) do not typically send
			mail.
	2. Terminology and Definitions		2. Terminology and Definitions
	This section defines terms used in the rest of the document.		This section defines terms used in the rest of the document.
	2.1. Conventions Used in This Document		2.1. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	skipping to change at page 6, line 16		skipping to change at page 6, line 17
	tree at which to register domain names "owned" by independent		tree at which to register domain names "owned" by independent
	organizations. Real-world examples are ".com", ".org", ".us", and		organizations. Real-world examples are ".com", ".org", ".us", and
	".gov.uk". Names at which such registrations occur are called Public		".gov.uk". Names at which such registrations occur are called Public
	Suffix Domains (PSDs), and a registration consists of a label		Suffix Domains (PSDs), and a registration consists of a label
	selected by the registrant to which a desirable PSD is appended. For		selected by the registrant to which a desirable PSD is appended. For
	example, "ietf.org" is a registered domain name, and ".org" is its		example, "ietf.org" is a registered domain name, and ".org" is its
	PSD.		PSD.
	2.3. Organizational Domain		2.3. Organizational Domain
	The term Organizational Domains is defined in [RFC7489] Section 3.2.		The term Organizational Domains is defined in DMARC [RFC7489]
			Section 3.2.
	2.4. Longest PSD		2.4. Longest PSD
	The longest PSD is the Organizational Domain with one label removed.		The longest PSD is the Organizational Domain with one label removed.
	It names the immediate parent node of the Organizational Domain in		It names the immediate parent node of the Organizational Domain in
	the DNS namespace tree.		the DNS namespace tree.
	2.5. Public Suffix Operator (PSO)		2.5. Public Suffix Operator (PSO)
	A Public Suffix Operator is an organization which manages operations		A Public Suffix Operator is an organization which manages operations
	skipping to change at page 11, line 46		skipping to change at page 11, line 46
	DOI 10.17487/RFC6973, July 2013,		DOI 10.17487/RFC6973, July 2013,
	<https://www.rfc-editor.org/info/rfc6973>.		<https://www.rfc-editor.org/info/rfc6973>.
	[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,		[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
	Trammell, B., Huitema, C., and D. Borkmann,		Trammell, B., Huitema, C., and D. Borkmann,
	"Confidentiality in the Face of Pervasive Surveillance: A		"Confidentiality in the Face of Pervasive Surveillance: A
	Threat Model and Problem Statement", RFC 7624,		Threat Model and Problem Statement", RFC 7624,
	DOI 10.17487/RFC7624, August 2015,		DOI 10.17487/RFC7624, August 2015,
	<https://www.rfc-editor.org/info/rfc7624>.		<https://www.rfc-editor.org/info/rfc7624>.
	[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky,		[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
	E., Ed., and K. Andersen, Ed., "Interoperability Issues		E., Ed., and K. Andersen, Ed., "Interoperability Issues
	between Domain-based Message Authentication, Reporting,		between Domain-based Message Authentication, Reporting,
	and Conformance (DMARC) and Indirect Email Flows",		and Conformance (DMARC) and Indirect Email Flows",
	RFC 7960, DOI 10.17487/RFC7960, September 2016,		RFC 7960, DOI 10.17487/RFC7960, September 2016,
	<https://www.rfc-editor.org/info/rfc7960>.		<https://www.rfc-editor.org/info/rfc7960>.
	[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is		[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
	Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,		Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
	November 2016, <https://www.rfc-editor.org/info/rfc8020>.		November 2016, <https://www.rfc-editor.org/info/rfc8020>.
End of changes. 18 change blocks.
	56 lines changed or deleted		64 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/