draft-ietf-dmarc-psd-00.txt   draft-ietf-dmarc-psd-01.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft fTLD Registry Services Internet-Draft fTLD Registry Services
Updates: 7489 (if approved) November 21, 2018 Updates: 7489 (if approved) January 14, 2019
Intended status: Informational Intended status: Informational
Expires: May 25, 2019 Expires: July 18, 2019
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-00 draft-ietf-dmarc-psd-01
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. DMARC policies can be organization can use to improve mail handling. DMARC policies can be
applied at the individual domain level or for a set of domains at the applied at the individual domain level or for a set of domains at the
organizational level. The design of DMARC precludes grouping organizational level. The design of DMARC precludes grouping
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 May 25, 2019. This Internet-Draft will expire on July 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 5 3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 5
3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 5 3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 5
3.2. Section 6.1 DMARC Policy Record . . . . . . . . . . . . . 5 3.2. Section 6.1 DMARC Policy Record . . . . . . . . . . . . . 5
3.3. Section 6.5. Domain Owner Actions . . . . . . . . . . . 5 3.3. Section 6.5. Domain Owner Actions . . . . . . . . . . . 5
3.4. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 5 3.4. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 5
3.5. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 6 3.5. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 6
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 6 4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. DMARC Public Suffix Domain (PSD) Registry 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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 [RFC7489] allows policy policy information to email receivers. DMARC [RFC7489] allows policy
to be specified for both individual domains and sets of domains to be specified for both individual domains and sets of domains
within a single organization. For domains above the organizational within a single organization. For domains above the organizational
level in the DNS tree, policy can only be published for the exact level in the DNS tree, policy can only be published for the exact
domain. There is no method available to such domains to express domain. There is no method available to such domains to express
lower level policy or receive feedback reporting for sets of domains. lower level policy or receive feedback reporting for sets of domains.
skipping to change at page 4, line 15 skipping to change at page 4, line 14
benefits of DMARC [RFC7489] to extend to the entire PSD, including benefits of DMARC [RFC7489] to extend to the entire PSD, including
cousin domains of registered organizations. cousin domains of registered organizations.
Due to the design of DMARC [RFC7489] and the nature of the Internet Due to the design of DMARC [RFC7489] and the nature of the Internet
email architecture [RFC5598], there are interoperability issues email architecture [RFC5598], there are interoperability issues
associated 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 applicable to PSDs, since they [RFC7960]. These issues are not applicable to PSDs, since they
(e.g., the ".gov.example" used above) do not send mail. (e.g., the ".gov.example" used above) do not send mail.
DMARC [RFC7489], by design, does not support usage by PSD operators. DMARC [RFC7489], by design, does not support usage by PSOs. For PSDs
For PSDs that require use of DMARC [RFC7489], an extension of DMARC that require use of DMARC [RFC7489], an extension of DMARC reporting
reporting and enforcement capability is needed for PSD operators to and enforcement capability is needed for PSO to effectively manage
effectively manage and monitor implementation of PSD requirements. and monitor implementation of PSD requirements.
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
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". They are not available for private
registration. In many cases the public portion of the DNS tree is registration. In many cases the public portion of the DNS tree is
more than one level deep. PSD DMARC includes all public domains more than one level deep. PSD DMARC includes all public domains
skipping to change at page 5, line 36 skipping to change at page 5, line 36
References to "Domain Owners" also apply to PSOs. References to "Domain Owners" also apply to PSOs.
3.2. Section 6.1 DMARC Policy Record 3.2. Section 6.1 DMARC Policy Record
PSD DMARC records are published as a subdomain of the PSD. For the PSD DMARC records are published as a subdomain of the PSD. For the
PSD ".example", the PSO would post DMARC policy in a TXT record at PSD ".example", the PSO would post DMARC policy in a TXT record at
"_dmarc.example". "_dmarc.example".
3.3. Section 6.5. Domain Owner Actions 3.3. Section 6.5. Domain Owner Actions
In addition to the DMARC [RFC7489] domain owner actions, PSOs will In addition to the DMARC [RFC7489] domain owner actions, PSOs that
need to update the "DMARC Public Suffix Domain (PSD) Registry". This require use of DMARC ought to make that information available to
registry is defined in Section 6.1. receivers.
3.4. Section 6.6.3. Policy Discovery 3.4. 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.3) of the
Organizational Domain is listed in the DMARC PSD Registry (defined Organizational Domain is one that the receiver has determined is
in Section 6.1), the Mail Receiver MUST query the DNS for a DMARC acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for
TXT record at the DNS domain matching the longest PSD a DMARC TXT record at the DNS domain matching the longest PSD
(Section 2.3) in place of the RFC5322.From domain in the message (Section 2.3) in place of the RFC5322.From domain in the message
(if different). A possibly empty set of records is returned. (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.cctld", the query for PSD DMARC "example.compute.cloudcompany.com.cctld", the query for PSD DMARC
would use "compute.cloudcompany.com.cctld" as the longest PSD would use "compute.cloudcompany.com.cctld" as the longest PSD
(Section 2.3). The receiver would check to see if that PSD is listed (Section 2.3). The receiver would check to see if that PSD is listed
in the DMARC PSD Registry, and if so, perform the policy lookup at in the DMARC PSD Registry, and if so, perform the policy lookup at
"_dmarc.compute.cloudcompany.com.cctld". "_dmarc.compute.cloudcompany.com.cctld".
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 [RFC7489] policy. Specifically, domains that have published a DMARC [RFC7489] policy. Specifically,
this is not a mechanism to provide feedback addresses (RUA/RUF) when this is not a mechanism to provide feedback addresses (RUA/RUF) when
an Organizational Domain has declined to do so. an Organizational Domain has declined to do so.
3.5. Section 7. DMARC Feedback 3.5. 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 desired and useful. Because of the constraints on PSD domains is desired and useful. See Section 4 for discussion of
DMARC scope, there are no significant privacy considerations Privacy Considerations.
associated with this reporting (See Section 4).
4. Privacy Considerations 4. Privacy Considerations
This document does not significantly change the Privacy These privacy considerations are developed based on the requiremetns
Considerations of [RFC7489]. of [RFC6973]. The Privacy Considerations of [RFC7489] apply to 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, create
leakage of information outside of an organization to the PSO. There leakage of information outside of an organization to the PSO. This
are roughly three cases to consider: leakage could be potentially be utilized as part of a program of
pervasive surveillance (See [RFC7624]). There are roughly three
cases to consider:
o Branded PSDs (e.g., ".google"), RUA and RUF reports based on PSD o Single Organization PSDs (e.g., ".google"), RUA and RUF reports
DMARC have the potential to contain information about emails based on PSD DMARC have the potential to contain information about
related to entities managed by the organization. Since both the emails related to entities managed by the organization. Since
PSO and the Organizational Domain owners are common, there is no both the PSO and the Organizational Domain owners are common,
privacy risk for either normal or non-existent Domain reporting. there is no additional privacy risk for either normal or non-
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
not publish a DMARC policy at the organizational or host level. not publish a DMARC policy at the organizational or host level.
For domains that do publish the required DMARC policy records, the For domains that do publish the required DMARC policy records, the
feedback reporting addresses (RUA and RUF) of the organization (or feedback reporting addresses (RUA and RUF) of the organization (or
hosts) will be used. Since PSD DMARC is limited to PSDs that hosts) will be used. The only direct feedback leakage risk for
mandate Organizational Domains publish DMARC policy for existing these PSDs are for Organizational Domains that are out of
domains, the risk of this issue is limited to Organizational compliance with PSD policy. Data on non-existent cousin domains
Domains that are out of compliance with PSD policy. would be sent to the PSO.
o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
usage. Privacy risks for Organizational Domains within such PSDs usage. Privacy risks for Organizational Domains that have not
would be significant. This is mitigated by the limitation to only deployed DMARC within such PSDs are significant. For non-DMARC
include PSDs listed in the public IANA DMARC PSD Registry Organizational Domains, all DMARC feedback will be directed to the
described in Section 6.1. PSO. PSD DMARC is opt-out (by publishing a DMARC record at the
Organizational Domain level) vice opt-in, which would be the more
desirable characteristic.
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 is best 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
DMARC for Organizational Domains in multi-organization PSDs that do
not particpate in DMARC, any Feedback Reporting related to multi-
organizational PSDs ought to be limited to non-existent domains
except in cases where the reporter knows that PSO requires use of
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]. [RFC7489] and [RFC7960].
6. IANA Considerations
This section describes actions requested to be completed by IANA.
6.1. DMARC Public Suffix Domain (PSD) Registry
IANA is requested to create a new DMARC Public Suffix Domain (PSD)
Registry within the Domain-based Message Authentication, Reporting,
and Conformance (DMARC) Parameters Registry.
Names of PSDs participating in PSD DMARC must be registered with IANA The risks of the issues identified in [RFC7489], Section 12.5,
in this new sub-registry. New entries are assigned only for PSDs External Reporting Addresses, are amplified by PSD DMARC. By design,
that require use of DMARC. The requirement has to be documented in a PSD DMARC causes unrequested reporting of feedback to entities
manner that satisfies the terms of Expert Review, per [RFC5226]. The external to the Organizational Domain. This is discussed in more
Designated Expert needs to confirm that provided documentation detail in Section 4.
adequately describes PSD policy to require domain owners to use DMARC
or that all domain owners are part of a single organization with the
PSO.
The initial set of entries in this registry is as follows: 6. IANA Considerations
+-------------+----------------+---------------+ This document does not require any IANA actions.
| PSD | Reference | Status |
+-------------+----------------+---------------+
| .bank | this document | current |
+-------------+----------------+---------------+
| .insurance | this document | current |
+-------------+----------------+---------------+
| .gov.uk | this document | current |
+-------------+----------------+---------------+
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 8, line 25 skipping to change at page 8, line 16
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,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[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
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009, DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>. <https://www.rfc-editor.org/info/rfc5598>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., 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. 24 change blocks. 
74 lines changed or deleted 72 lines changed or added

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