f.out		draft-ietf-dmarc-psd-09.txt
	Network Working Group S. Kitterman		Network Working Group S. Kitterman
	Internet-Draft fTLD Registry Services		Internet-Draft fTLD Registry Services
	Intended status: Experimental September 1, 2020		Intended status: Experimental September 22, 2020
	Expires: March 5, 2021		Expires: March 26, 2021
	Experimental DMARC Extension For Public Suffix Domains		DMARC (Domain-based Message Authentication, Reporting, and Conformance)
			Extension For PSDs (Public Suffix Domains)
	draft-ietf-dmarc-psd-09		draft-ietf-dmarc-psd-09
	Abstract		Abstract
	DMARC (Domain-based Message Authentication, Reporting, and		DMARC (Domain-based Message Authentication, Reporting, and
	Conformance) is a scalable mechanism by which a mail-originating		Conformance) is a scalable mechanism by which a mail-originating
	organization can express domain-level policies and preferences for		organization can express domain-level policies and preferences for
	message validation, disposition, and reporting, that a mail-receiving		message validation, disposition, and reporting, that a mail-receiving
	organization can use to improve mail handling. The design of DMARC		organization can use to improve mail handling. The design of DMARC
	presumes that domain names represent either nodes in the tree below		presumes that domain names represent either nodes in the tree below
	skipping to change at page 1, line 48		skipping to change at page 1, line 49
	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 March 5, 2021.		This Internet-Draft will expire on March 26, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . 5
	2.4. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 6		2.4. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . . . . . . 7		3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Changes in Section 6.3 "General Record Format" . . . . . 7		3.2. Changes in Section 6.3 "General Record Format" . . . . . 6
	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" . . . . . . . 7
	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 . . . . . . . . . . . . . . . . . . . . 9		4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . . . . . 10
	Appendix A. PSD DMARC Privacy Concern Mitigation Experiment . . 12		Appendix A. PSD DMARC Privacy Concern Mitigation Experiment . . 11
	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 . . . . . . . . . . . . . . . . . . . 13
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
	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. DMARC leverages
			public suffix lists to determine which domains are organizational
	To determine the organizational domain for a message under		domains. It presumes that public suffix list listed domains are not
	evaluation, and thus where to look for a policy statement, DMARC		organizational domains and not subject to DMARC processing; domains
	makes use of a Public Suffix List. The process for doing this can be		are either organizational domains, sub-domains of organizational
	found in Section 3.2 of the DMARC specification.		domains, or listed on a public suffix list. For domains listed in a
			public suffix list, i.e. TLDs and domains that exist between TLDs and
	DMARC as specified presumes that domain names present in a PSL are		organization level domains, policy can only be published for the
	not organizational domains and thus not subject to DMARC processing;		exact domain. No method is available for these domains to express
	domains are either organizational domains, sub-domains of		policy or receive feedback reporting for sub-domains. This missing
	organizational domains, or listed on a PSL. For domains listed in a		method allows for the abuse of non-existent organizational-level
	PSL, i.e., TLDs and domains that exist between TLDs and organization		domains and prevents identification of domain abuse in email.
	level domains, policy can only be published for the exact domain. No
	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
	algorithm cited above, in an attempt to mitigate this abuse.
	1.1. Example
	As an example, imagine a country code TLD (ccTLD) which has public		As an example, imagine a country code TLD (ccTLD) which has public
	subdomains for government and commercial use (".gov.example" and		subdomains for government and commercial use (.gov.example and
	".com.example"). A PSL whose maintainer is aware of this country's		.com.example). Suppose there exists a registered domain
	domain structurewould include entries for both of these in the PSL,		"tax.gov.example" that is responsible for taxation in this imagined
	indicating that they are PSDs below which registrations can occur.		country. However, by exploiting the typically unauthenticated nature
	Suppose further that there exists a domain "tax.gov.example",		of email, there are regular malicious campaigns to impersonate this
	registered within ".gov.example", that is responsible for taxation in
	this imagined country.
	However, by exploiting the typically unauthenticated nature of email,
	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". These domains are not registered. Within the
			".gov.example" public suffix, use of DMARC has been mandated, so
	Within the ".gov.example" public suffix, use of DMARC has been		"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. However, due to DMARC's current method		mail sent from @gov.example. However, due to DMARC's current method
	of discovering and applying policy at the organizational domain		of discovering and applying policy at the organizational domain
	level, the non-existent organizational domain of @t4x.gov.example		level, the non-existent organizational domain of @t4x.gov.example
	does not and cannot fall under a DMARC policy.		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
	This document provides a simple extension to DMARC [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
	o Provides controls to mitigate potential privacy considerations		o Provides controls to mitigate potential privacy considerations
	associated with this extension		associated with this extension
	This document also provides a new DMARC tag to indicate requested		This document also provides a new DMARC [RFC7489] tag to indicate
	handling policy for non-existent subdommains. This is provided		requested handling policy for non-existent subdommains. This is
	specifically to support phased deployment of PSD DMARC, but is		provided specifically to support phased deployment of PSD DMARC, but
	expected to be useful more generally. Undesired rejection risks for		is expected to be useful more generally. Undesired rejection risks
	mail purporting to be from domains that do not exist are		for 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 DMARC [RFC7489], DMARC		requirements. Based on the requirements of DMARC [RFC7489], DMARC
	should function above the organizational level for exact domain		should function above the organizational level for exact domain
	matches (i.e. if a DMARC record were published for 'example', then		matches (i.e. if a DMARC record were published for 'example', then
	mail from example@example should be subject to DMARC processing).		mail from example@example should be subject to DMARC processing).
	Testing had revealed that this is not consistently applied in		Testing had revealed that this is not consistently applied in
	different implementations.		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 DMARC [RFC7489]. They		Organizational Domains as discussed in DMARC [RFC7489]. They
	control 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
	skipping to change at page 5, line 26		skipping to change at page 5, line 5
	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 [RFC7489] and the nature of the Internet
	architecture [RFC5598], there are interoperability issues associated		email architecture [RFC5598], there are interoperability issues
	with DMARC [RFC7489] deployment. These are discussed in		associated with DMARC [RFC7489] deployment. These are discussed in
	Interoperability Issues between DMARC and Indirect Email Flows		Interoperability Issues between DMARC and Indirect Email Flows
	[RFC7960]. These issues are not typically applicable to PSDs, since		[RFC7960]. These issues are not typically applicable to PSDs, since
	they (e.g., the ".gov.example" used above) do not typically send		they (e.g., the ".gov.example" used above) do not typically send
	mail.		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
	skipping to change at page 6, line 23		skipping to change at page 6, line 4
	PSD.		PSD.
	2.3. Organizational Domain		2.3. Organizational Domain
	The term Organizational Domains is defined in DMARC [RFC7489]		The term Organizational Domains is defined in DMARC [RFC7489]
	Section 3.2.		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
	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
	within a PSD, particularly the DNS records published for names at and		within a PSD, particularly the DNS records published for names at and
	under that domain name.		under that domain name.
	2.6. PSO Controlled Domain Names		2.6. PSO Controlled Domain Names
	PSO Controlled Domain Names are names in the DNS that are managed by		PSO Controlled Domain Names are names in the DNS that are managed by
	skipping to change at page 6, line 47		skipping to change at page 6, line 26
	".co.uk") name components, depending on PSD policy.		".co.uk") name components, depending on PSD policy.
	2.7. Non-existent Domains		2.7. Non-existent Domains
	For DMARC purposes, a non-existent domain is a domain for which there		For DMARC purposes, a non-existent domain is a domain for which there
	is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This		is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This
	is a broader definition than that in NXDOMAIN [RFC8020].		is a broader definition than that in NXDOMAIN [RFC8020].
	3. PSD DMARC Updates to DMARC Requirements		3. PSD DMARC Updates to DMARC Requirements
	This document updates DMARC as follows:		This document updates DMARC [RFC7489] as follows:
	3.1. General Updates		3.1. General Updates
	References to "Domain Owners" also apply to PSOs.		References to "Domain Owners" also apply to PSOs.
	3.2. Changes in Section 6.3 "General Record Format"		3.2. Changes in Section 6.3 "General Record Format"
	A new tag is added after "fo":		A new tag is added after "fo":
	np: Requested Mail Receiver policy for non-existent subdomains		np: Requested Mail Receiver policy for non-existent subdomains
	(plain-text; OPTIONAL). Indicates the policy to be enacted by the		(plain-text; OPTIONAL). Indicates the policy to be enacted by the
	Receiver at the request of the Domain Owner. It applies only to		Receiver at the request of the Domain Owner. It applies only to
	non-existent subdomains of the domain queried and not to either		non-existent subdomains of the domain queried and not to either
	existing subdomains or the domain itself. Its syntax is identical		existing subdomains or the domain itself. Its syntax is identical
	to that of the "p" tag defined below. If the 'np' tag is absent,		to that of the "p" tag defined below. If the 'np' tag is absent,
	the policy specified by the "sp" tag (if the 'sp' tag is present)		the policy specified by the "sp" tag (if the 'sp' tag is present)
	or the policy specified by the "p" tag, if the 'sp' tag is not		or the policy specified by the "p" tag, if the 'sp' tag is not
	present, MUST be applied for non-existent subdomains. Note that		present, MUST be applied for non-existent subdomains. Note that
	"np" will be ignored for DMARC records published on subdomains of		"np" will be ignored for DMARC records published on subdomains of
	Organizational Domains and PSDs due to the effect of the DMARC		Organizational Domains and PSDs due to the effect of the DMARC
	policy discovery mechanism described in DMARC Section 6.6.3.		policy discovery mechanism described in DMARC [RFC7489]
			Section 6.6.3.
	The following tag definitions from DMARC are updated:		The following tag definitions from DMARC [RFC7489] are updated:
	p: The sentence 'Policy applies to the domain queried and to		p: The sentence 'Policy applies to the domain queried and to
	subdomains, unless subdomain policy is explicitly described using		subdomains, unless subdomain policy is explicitly described using
	the "sp" tag' is updated to read 'Policy applies to the domain		the "sp" tag' is updated to read 'Policy applies to the domain
	queried and to subdomains, unless subdomain policy is explicitly		queried and to subdomains, unless subdomain policy is explicitly
	described using the "sp" or "np" tags.'		described using the "sp" or "np" tags.'
	sp: The sentence 'If absent, the policy specified by the "p" tag		sp: The sentence 'If absent, the policy specified by the "p" tag
	MUST be applied for subdomains' is updated to read 'If both the		MUST be applied for subdomains' is updated to read 'If both the
	'sp' tag is absent and the 'np' tag is either absent or not		'sp' tag is absent and the 'np' tag is either absent or not
	skipping to change at page 8, line 6		skipping to change at page 7, line 32
	for doing so. See the [this document] experiment description		for doing so. See the [this document] experiment description
	(Appendix A).		(Appendix A).
	3.4. Changes in Section 6.6.1 "Extract Author Domain"		3.4. Changes in Section 6.6.1 "Extract Author Domain"
	Experience with DMARC has shown that some implementations short-		Experience with DMARC has shown that some implementations short-
	circuit messages, bypassing DMARC policy application, when the domain		circuit messages, bypassing DMARC policy application, when the domain
	name extracted by the receiver (from the RFC5322.From) is on the		name extracted by the receiver (from the RFC5322.From) is on the
	public suffix list used by the receiver. This negates the capability		public suffix list used by the receiver. This negates the capability
	being created by this specification. Therefore, the following		being created by this specification. Therefore, the following
	paragraph is appended to Section 6.6.1 of DMARC:		paragraph is appended to Section 6.6.1 of DMARC [RFC7489]:
	Note that domain names that appear on a public suffix list are not		Note that domain names that appear on a public suffix list are not
	exempt from DMARC policy application and reporting.		exempt from DMARC policy application and reporting.
	3.5. Changes in Section 6.6.3 "Policy Discovery"		3.5. Changes in Section 6.6.3 "Policy Discovery"
	A new step between step 3 and 4 is added:		A new step between step 3 and 4 is added:
	3A. If the set is now empty and the longest PSD (Section 2.4) of the		3A. If the set is now empty and the longest PSD (Section 2.4) of the
	Organizational Domain is one that the receiver has determined is		Organizational Domain is one that the receiver has determined is
End of changes. 22 change blocks.
	71 lines changed or deleted		50 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/