draft-ietf-dmarc-psd-01.txt   draft-ietf-dmarc-psd-02.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) January 14, 2019 Intended status: Experimental April 9, 2019
Intended status: Informational Expires: October 11, 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-01 draft-ietf-dmarc-psd-02
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 43
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 18, 2019. This Internet-Draft will expire on October 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 28 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 4 2.1. Conventions Used in This Document . . . . . . . . . . . . 4
2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 4 2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 4
2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 4 2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 4
2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 5 2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 4
2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 5 2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 5
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
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix B. DMARC PSD Registry Example . . . . . . . . . . . . . 9
B.1. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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 7, line 6 skipping to change at page 6, line 49
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. The only direct feedback leakage risk for hosts) will be used. The only direct feedback leakage risk for
these PSDs are for Organizational Domains that are out of these PSDs are for Organizational Domains that are out of
compliance with PSD policy. Data on non-existent cousin domains compliance with PSD policy. Data on non-existent cousin domains
would be sent to the PSO. 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 that have not usage: Privacy risks for Organizational Domains that have not
deployed DMARC within such PSDs are significant. For non-DMARC deployed DMARC within such PSDs are significant. For non-DMARC
Organizational Domains, all DMARC feedback will be directed to the Organizational Domains, all DMARC feedback will be directed to the
PSO. PSD DMARC is opt-out (by publishing a DMARC record at the PSO. PSD DMARC is opt-out (by publishing a DMARC record at the
Organizational Domain level) vice opt-in, which would be the more Organizational Domain level) vice opt-in, which would be the more
desirable characteristic. desirable characteristic. This means that any non-DMARC
organizational domain would have it's feedback reports redirected
to the PSDo. The content of such reports, particularly for
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 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 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
skipping to change at page 8, line 16 skipping to change at page 8, line 11
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
[psddmarc.org]
multiple, "PSD DMARC Web Site", April 2019,
<https://psddmarc.org/>.
[PSL] multiple, "Public Suffix List", April 2019,
<https://publicsuffix.org/>.
[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., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
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>.
skipping to change at page 8, line 44 skipping to change at page 9, line 5
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
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 PSDo and that
the relevant PSDo 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 PSDos 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 IANA registry
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 below
Appendix B. DMARC PSD Registry Example
To faciliate experimentation around data leakage mitigation, a sample
service is available at [psddmarc.org]. It was developed based on
the requirements suggested for an IANA registry in an earlier
revision of this draft. Usage of the service is described on the web
site.
B.1. DMARC Public Suffix Domain (PSD) Registry
[psddmarc.org] provides a DMARC Public Suffix Domain (PSD) Registry
as a stand-alone DNS query service.
Names of PSDs participating in PSD DMARC must be registered this new
registry. New entries are assigned only for PSDs that require use of
DMARC. The requirement has to be documented in a manner that
satisfies the terms of Expert Review,per [RFC5226]. The Designated
Expert needs to confirm that provided documentation 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:
+-------------+---------------+
| PSD | Status |
+-------------+---------------+
| .bank | current |
+-------------+---------------+
| .insurance | current |
+-------------+---------------+
| .gov.uk | current |
+-------------+---------------+
Acknowledgements Acknowledgements
TBS Thanks to the following individuals for their contributions (both
public and private) to improving this document. Special shout out to
Dave Crocker for naming the beast.
Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen,
Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig
Schwartz, Alessandro Vesely, and Tim Wicinski
Author's Address Author's Address
Scott Kitterman Scott Kitterman
fTLD Registry Services fTLD Registry Services
600 13th Street, NW, Suite 400 600 13th Street, NW, Suite 400
Washington, DC 20005 Washington, DC 20005
United States of America United States of America
Phone: +1 301 325-5475 Phone: +1 301 325-5475
Email: scott@kitterman.com Email: scott@kitterman.com
 End of changes. 11 change blocks. 
11 lines changed or deleted 108 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/