draft-ietf-dmarc-psd-08.txt   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 March 12, 2020 Intended status: Experimental September 22, 2020
Expires: September 13, 2020 Expires: March 26, 2021
DMARC (Domain-based Message Authentication, Reporting, and Conformance) DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Extension For PSDs (Public Suffix Domains) Extension For PSDs (Public Suffix Domains)
draft-ietf-dmarc-psd-08 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
which registrations occur, or nodes where registrations have which registrations occur, or nodes where registrations have
skipping to change at page 1, line 49 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 September 13, 2020. 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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
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. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Organizational Domain . . . . . . . . . . . . . . . . . . 5
2.4. Organizational Domain . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 6 3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 6
3.2. Section 6.3 General Record Format . . . . . . . . . . . . 6 3.2. Changes in Section 6.3 "General Record Format" . . . . . 6
3.3. Section 6.5. Domain Owner Actions . . . . . . . . . . . 7 3.3. Changes in Section 6.5 "Domain Owner Actions" . . . . . . 7
3.4. Section 6.6.1. Extract Author Domain . . . . . . . . . . 7 3.4. Changes in Section 6.6.1 "Extract Author Domain" . . . . 7
3.5. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 7 3.5. Changes in Section 6.6.3 "Policy Discovery" . . . . . . . 7
3.6. 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 . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 11 Appendix A. PSD DMARC Privacy Concern Mitigation Experiment . . 11
A.1. PSD DMARC Privacy Concern Mitigation . . . . . . . . . . 12 Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12
A.2. Non-Existent Subdomain Policy . . . . . . . . . . . . . . 12 B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 12
Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 13 B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 12
B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 13 B.3. DMARC PSD PSL Extension . . . . . . . . . . . . . . . . . 13
B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 13 Appendix C. Implementations . . . . . . . . . . . . . . . . . . 13
B.3. DMARC PSD PSL Extension . . . . . . . . . . . . . . . . . 14 C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 13
C.2. Zdkimfilter Module . . . . . . . . . . . . . . . . . . . 13
Appendix C. Implementations . . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
C.2. Zdkimfilter Module . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
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. DMARC leverages and their sub-domains within a single organization. DMARC leverages
public suffix lists to determine which domains are organizational public suffix lists to determine which domains are organizational
domains. It presumes that public suffix list listed domains are not domains. It presumes that public suffix list listed domains are not
organizational domains and not subject to DMARC processing; domains organizational domains and not subject to DMARC processing; domains
skipping to change at page 3, line 38 skipping to change at page 3, line 35
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). Suppose there exists a registered domain .com.example). Suppose there exists a registered domain
"tax.gov.example" that is responsible for taxation in this imagined "tax.gov.example" that is responsible for taxation in this imagined
country. However, by exploiting the typically unauthenticated nature country. However, by exploiting the typically unauthenticated nature
of email, there are regular malicious campaigns to impersonate this 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". These domains are not registered. Within the "t4x.gov.example". These domains are not registered. Within the
".gov.example" public suffix, use of DMARC has been mandated, so ".gov.example" public suffix, use of DMARC has been mandated, so
"gov.example" publishes the following DMARC record: "gov.example" publishes the following DMARC DNS record:
"v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.service.gov.example"
at
_dmarc.gov.example. _dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject; "
"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 @tax.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.
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 express policy at the operators of Public Suffix Domains (PSDs) to:
level of the PSD that covers all organizational domains that do not
explicitly publish DMARC records, extends the DMARC policy query o Express policy at the level of the PSD that covers all
functionality to detect and process such a policy, describes receiver organizational domains that do not explicitly publish DMARC
feedback for such policies, and provides controls to mitigate records
potential privacy considerations associated with this extension.
o Extends the DMARC policy query functionality to detect and process
such a policy
o Describes receiver feedback for such policies
o Provides controls to mitigate potential privacy considerations
associated with this extension
This document also provides a new DMARC [RFC7489] tag to indicate This document also provides a new DMARC [RFC7489] tag to indicate
requested handling policy for non-existent subdommains. This is requested handling policy for non-existent subdommains. This is
provided specifically to support phased deployment of PSD DMARC, but provided specifically to support phased deployment of PSD DMARC, but
is expected to be useful more generally. Undesired rejection risks is expected to be useful more generally. Undesired rejection risks
for 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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
"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
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Public Suffix Domain (PSD) 2.2. Public Suffix Domain (PSD)
The global Internet Domain Name System (DNS) is documented in The global Internet Domain Name System (DNS) is documented in
numerous Requests for Comment (RFC). It defines a tree of names numerous Requests for Comment (RFC). It defines a tree of names
starting with root, ".", immediately below which are Top Level Domain starting with root, ".", immediately below which are Top Level Domain
names such as ".com" and ".us". They are not available for private names such as ".com" and ".us". The domain name structure consists
registration. In many cases the public portion of the DNS tree is of a tree of names, each of which is made of a sequence of words
more than one level deep. The domain name structure consists of a
tree of names, each of which is made of a sequence of words
("labels") separated by period characters. The root of the tree is ("labels") separated by period characters. The root of the tree is
simply called ".". The Internet community at large, through simply called ".". The Internet community at large, through
processes and policies external to this work, selects points in this processes and policies external to this work, selects points in this
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. Longest PSD 2.3. Organizational Domain
The longest PSD is the Organizational Domain with one label removed.
2.4. 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
The longest PSD is the Organizational Domain with one label removed.
2.5. Public Suffix Operator (PSO) 2.5. Public Suffix Operator (PSO)
A Public Suffix Operator manages operations within its PSD. A Public Suffix Operator is an organization which manages operations
within a PSD, particularly the DNS records published for names at and
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
a PSO and are not available for use as Organizational Domains. a PSO and are not available for use as Organizational Domains. PSO
Depending on PSD policy, these will have one (e.g., ".com") or more Controlled Domain Names may have one (e.g., ".com") or more (e.g.,
(e.g., ".co.uk") name components. ".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 [RFC7489] 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. 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)
skipping to change at page 7, line 19 skipping to change at page 7, line 17
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
applicable, the policy specified by the "p" tag MUST be applied applicable, the policy specified by the "p" tag MUST be applied
for subdomains. for subdomains.
3.3. Section 6.5. Domain Owner Actions 3.3. Changes in Section 6.5 "Domain Owner Actions"
In addition to the DMARC domain owner actions, PSOs that require use In addition to the DMARC domain owner actions, PSOs that require use
of DMARC and participate in PSD DMARC ought to make that information of DMARC and participate in PSD DMARC ought to make that information
available to receivers. The mechanism for doing so is one of the available to receivers. This document is an experimental mechanism
experimental elements of this document. See the experiment for doing so. See the [this document] experiment description
description (Appendix A). (Appendix A).
3.4. 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 [RFC7489]: 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. 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.3) 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
acceptable for PSD DMARC (discussed in the experiment description acceptable for PSD DMARC (discussed in the [this document]
(Appendix A)), the Mail Receiver MUST query the DNS for a DMARC experiment description (Appendix A)), the Mail Receiver MUST query
TXT record at the DNS domain matching the longest PSD the DNS for a DMARC TXT record at the DNS domain matching the
(Section 2.3) in place of the RFC5322.From domain in the message [this document] longest PSD (Section 2.4) in place of the
(if different). A possibly empty set of records is returned. RFC5322.From domain in the message (if different). A possibly
empty set of records is returned.
As an example, for a message with the Organizational Domain of As an example, for a message with the Organizational Domain of
"example.compute.cloudcompany.com.example", the query for PSD DMARC "example.compute.cloudcompany.com.example", the query for PSD DMARC
would use "compute.cloudcompany.com.example" as the longest PSD would use "compute.cloudcompany.com.example" as the [this document]
(Section 2.3). The receiver would check to see if that PSD is listed longest PSD (Section 2.4). The receiver would check to see if that
in the DMARC PSD Registry, and if so, perform the policy lookup at PSD is listed in the DMARC PSD Registry, and if so, perform the
"_dmarc.compute.cloudcompany.com.example". policy lookup at "_dmarc.compute.cloudcompany.com.example".
Note: Because the PSD policy query comes after the Organizational Note: Because the PSD policy query comes after the Organizational
Domain policy query, PSD policy is not used for Organizational Domain policy query, PSD policy is not used for Organizational
domains that have published a DMARC policy. Specifically, this is domains that have published a DMARC policy. Specifically, this is
not a mechanism to provide feedback addresses (RUA/RUF) when an not a mechanism to provide feedback addresses (RUA/RUF) when an
Organizational Domain has declined to do so. Organizational Domain has declined to do so.
3.6. Section 7. DMARC Feedback 3.6. Changes in Section 7 "DMARC Feedback"
Operational note for PSD DMARC: For PSOs, feedback for non-existent Operational note for PSD DMARC: For PSOs, feedback for non-existent
domains is desirable and useful, just as it is for org-level DMARC domains is desirable and useful, just as it is for org-level DMARC
operators. See Section 4 of this document for discussion of Privacy operators. See Section 4 of [this document] for discussion of
Considerations. Privacy Considerations for PSD DMARC.
4. Privacy Considerations 4. Privacy Considerations
These privacy considerations are developed based on the requirements These privacy considerations are developed based on the requirements
of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this of [RFC6973]. Additionally, the Privacy Considerations of [RFC7489]
document. apply to the mechanisms described by this document.
4.1. Feedback leakage 4.1. Feedback leakage
Providing feedback reporting to PSOs can, in some cases, create Providing feedback reporting to PSOs can, in some cases, cause
leakage of information outside of an organization to the PSO. This information to leak out of an organization to the PSO. This leakage
leakage could potentially be utilized as part of a program of could potentially be utilized as part of a program of pervasive
pervasive surveillance (See [RFC7624]). There are roughly three surveillance (See [RFC7624]). There are roughly three cases to
cases to consider: consider:
o Single Organization PSDs (e.g., ".google"), RUA and RUF reports o Single Organization PSDs (e.g., ".google"), RUA and RUF reports
based on PSD DMARC have the potential to contain information about based on PSD DMARC have the potential to contain information about
emails related to entities managed by the organization. Since emails related to entities managed by the organization. Since
both the PSO and the Organizational Domain owners are common, both the PSO and the Organizational Domain owners are common,
there is no additional privacy risk for either normal or non- there is no additional privacy risk for either normal or non-
existent Domain reporting due to PSD DMARC. existent Domain reporting due to PSD DMARC.
o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
PSD DMARC based reports will only be generated for domains that do PSD DMARC based reports will only be generated for domains that do
skipping to change at page 9, line 20 skipping to change at page 9, line 20
Organizational Domain level) vice opt-in, which would be the more Organizational Domain level) vice opt-in, which would be the more
desirable characteristic. This means that any non-DMARC desirable characteristic. This means that any non-DMARC
organizational domain would have its feedback reports redirected organizational domain would have its feedback reports redirected
to the PSO. The content of such reports, particularly for to the PSO. The content of such reports, particularly for
existing domains, is privacy sensitive. existing domains, is privacy sensitive.
PSOs will receive feedback on non-existent domains, which may be PSOs will receive feedback on non-existent domains, which may be
similar to existing Organizational Domains. Feedback related to such similar to existing Organizational Domains. Feedback related to such
cousin domains have a small risk of carrying information related to cousin domains have a small risk of carrying information related to
an actual Organizational Domain. To minimize this potential concern, an actual Organizational Domain. To minimize this potential concern,
PSD DMARC feedback is best limited to Aggregate Reports. Feedback PSD DMARC feedback MUST be limited to Aggregate Reports. Feedback
Reports carry more detailed information and present a greater risk. Reports carry more detailed information and present a greater risk.
Due to the inherent Privacy and Security risks associated with PSD Due to the inherent Privacy and Security risks associated with PSD
DMARC for Organizational Domains in multi-organization PSDs that do DMARC for Organizational Domains in multi-organization PSDs that do
not particpate in DMARC, any Feedback Reporting related to multi- not particpate in DMARC, any Feedback Reporting related to multi-
organizational PSDs ought to be limited to non-existent domains organizational PSDs MUST be limited to non-existent domains except in
except in cases where the reporter knows that PSO requires use of cases where the reporter knows that PSO requires use of DMARC.
DMARC.
5. Security Considerations 5. Security Considerations
This document does not change the Security Considerations of This document does not change the Security Considerations of
[RFC7489] and [RFC7960]. [RFC7489] and [RFC7960].
The risks of the issues identified in [RFC7489], Section 12.3, DNS The risks of the issues identified in [RFC7489], Section 12.3, DNS
Security, are amplified by PSD DMARC. In particular, DNS cache Security, are amplified by PSD DMARC. In particular, DNS cache
poisoning (or Name Chaining), see [RFC3833] for details, consequences poisoning (or Name Chaining), see [RFC3833] for details, consequences
are increased because a successful attack would potentially have a are increased because a successful attack would potentially have a
skipping to change at page 10, line 44 skipping to change at page 10, line 44
[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>.
7.2. Informative References 7.2. Informative References
[psddmarc.org] [psddmarc.org]
multiple, "PSD DMARC Web Site", April 2019, multiple, "PSD DMARC Web Site", April 2019,
<https://psddmarc.org/>. <https://psddmarc.org/>.
[PSL] multiple, "Public Suffix List", April 2019,
<https://publicsuffix.org/>.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August
2004, <https://www.rfc-editor.org/info/rfc3833>. 2004, <https://www.rfc-editor.org/info/rfc3833>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
skipping to change at page 11, line 38 skipping to change at page 11, line 33
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>.
Appendix A. The Experiment Appendix A. PSD DMARC Privacy Concern Mitigation Experiment
There are two experimental questions addressed in this document: one
regarding mitigation of PSD related privacy concerns and the other on
the utility of specifying separate DMARC policies for non-existent
sub-domains.
Aditionally, as of the writing of this document operational and
policy constraints prevent this experiment from being deployed
globally. If the experiment shows that PSD DMARC solves a real
problem and can be used at a large scale, the results could prove to
be useful in removing constraints outside of the IETF that would
permit broader deployment.
A.1. PSD DMARC Privacy Concern Mitigation
To mitigate the privacy concerns associated with Multi-organization
PSDs that do not mandate DMARC usage, see Section 4.1, a mechanism to
indicate which PSDs do not present this privacy risk is appropriate.
There are multiple approaches that are possible.
The experiment is to evaluate different possible approaches. The
experiment will be complete when there is rough consensus on a
technical approach that is demonstrated to be operationally usable
and effective at mitigating the privacy concern.
The mechanism needs the following attributes:
o Be reliably, publicly accessible
o Be under configuration control based on a public set of criteria
o List PSDs that either mandate DMARC for their registrants or for
which all lower level domains are controlled by the PSO and that
the relevant PSO has indicated a desire for the PSD to participate
in PSD DMARC
o Have a small operational footprint (e.g. provide a documented,
lightweight mechanism for developers and operators to retrieve the
list of PSD DMARC participants)
o Not allow PSO to add PSDs to the PSD DMARC participants list
without third party review
As of this writing, three approaches have been proposed. None of
them are ideal:
o An extension to the Public Suffix List at [PSL]
o A dedicated registry queried via DNS - an example of such a
service is described in Appendix B.1 below
o An IANA registry The experiment being performed has three different questions which
are looking to be addressed in this document.
A.2. Non-Existent Subdomain Policy o Section 3.2 modifies policy discovery to add an additional DNS
lookup. To determine if this lookup is useful, PSDs will add
additional DMARC records in place, and will analyze the DMARC
reports. Success will be determined if a consensus of PSDs that
publish DMARC records are able to collect useful data.
PSOs that plan to implement PSD DMARC have indicated that the ability o Section 3.2 adds the "np" tag for non-existent subdomains (DNS
to describe distinct policies for existing and non- existing sub- NXDOMAIN). PSOs wishing to test this will add this flag to their
domains would facilitate PSD DMARC deployment. There are also DMARC record, and will analyze DMARC reports for deployment.
suggestions that it would be more generally useful for DMARC. Success will be determined if organizations find explicitly
blocking non-existent subdomains domains desirable and provide
added value.
During the period of the experiment, uptake of the new 'np' tag will o Section 4.1 discusses three cases where providing feedback could
be evaluated to support assessment of the utility of including 'np' cause information to leak out of an organization. This experiment
in a future, non-experimental update. will analyze the feedback reports generated for each case to
determine if there is information leakage.
Appendix B. DMARC PSD Registry Examples Appendix B. DMARC PSD Registry Examples
To facilitate experimentation around data leakage mitigation, samples To facilitate experimentation around data leakage mitigation, samples
of the DNS based and IANA like registries are available at of the DNS based and IANA like registries are available at
[psddmarc.org]. [psddmarc.org].
B.1. DMARC PSD DNS Query Service B.1. DMARC PSD DNS Query Service
A sample stand-alone DNS query service is available at A sample stand-alone DNS query service is available at
 End of changes. 35 change blocks. 
144 lines changed or deleted 100 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/