< draft-ietf-dmarc-psd-02.txt   draft-ietf-dmarc-psd-03.txt >
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft fTLD Registry Services Internet-Draft fTLD Registry Services
Intended status: Experimental April 9, 2019 Intended status: Experimental May 7, 2019
Expires: October 11, 2019 Expires: November 8, 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-02 draft-ietf-dmarc-psd-03
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 43 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 October 11, 2019. This Internet-Draft will expire on November 8, 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 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 4 2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 5
2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 4 2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . 8
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
Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 9 Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 9
Appendix B. DMARC PSD Registry Example . . . . . . . . . . . . . 9 Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 10
B.1. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 10 B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix C. Implementation . . . . . . . . . . . . . . . . . . . 11
C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
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 3, line 36 skipping to change at page 3, line 38
in a mail delivery decision, but is not generally treated as in a mail delivery decision, but is not generally treated as
definitive on its own. definitive on its own.
This memo provides a simple extension to DMARC [RFC7489] to allow This memo provides a simple extension to DMARC [RFC7489] to allow
operators of Public Suffix Domains (PSDs) to express policy for operators of Public Suffix Domains (PSDs) to express policy for
groups of subdomains, extends the DMARC [RFC7489] policy query groups of subdomains, extends the DMARC [RFC7489] policy query
functionality to detect and process such a policy, describes receiver functionality to detect and process such a policy, describes receiver
feedback for such policies, and provides controls to mitigate feedback for such policies, and provides controls to mitigate
potential privacy considerations associated with this extension. potential privacy considerations associated with this extension.
As an additional benefit, the PSD DMARC extension will clarify
existing requirements. Based on the requirements of DMARC [RFC7489],
DMARC should function above the organizational level for exact domain
matches (i.e. if a DMARC record were published for 'example', then
mail from example@example should be subject to DMARC processing.
Testing had revealed that this is not consistently applied in
different implementations. PSD DMARC will help clarify that DMARC is
not limited to organizational domains and their sub-domains.
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
as Public for DMARC [RFC7489] purposes. They require the same as Public for DMARC [RFC7489] purposes. They require the same
protections as DMARC [RFC7489] Organizational Domains, but are protections as DMARC [RFC7489] Organizational Domains, but are
currently excluded. currently excluded.
skipping to change at page 6, line 13 skipping to change at page 6, line 31
"_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
[RFC7489] Section 7.3 Failure Reports MUST NOT be sent for PSD DMARC.
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. See Section 4 for discussion of domains is desired and useful. See Section 4 for discussion of
Privacy Considerations. Privacy Considerations.
4. Privacy Considerations 4. Privacy Considerations
These privacy considerations are developed based on the requiremetns These privacy considerations are developed based on the requiremetns
of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this
document. document.
skipping to change at page 7, line 7 skipping to change at page 7, line 27
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. This means that any non-DMARC desirable characteristic. This means that any non-DMARC
organizational domain would have it's feedback reports redirected organizational domain would have it's feedback reports redirected
to the PSDo. 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 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
skipping to change at page 9, line 24 skipping to change at page 9, line 42
technical approach that is demonstrated to be operationally usable technical approach that is demonstrated to be operationally usable
and effective at mitigating the privacy concern. and effective at mitigating the privacy concern.
The mechanism needs the following attributes: The mechanism needs the following attributes:
o Be reliably, publicly accessible o Be reliably, publicly accessible
o Be under configuration control based on a public set of criteria o Be under configuration control based on a public set of criteria
o List PSDs that either mandate DMARC for their registrants or for o List PSDs that either mandate DMARC for their registrants or for
which all lower level domains are controlled by the PSDo and that which all lower level domains are controlled by the PSO and that
the relevant PSDo has indicated a desire for the PSD to the relevant PSO has indicated a desire for the PSD to participate
participate in PSD DMARC in PSD DMARC
o Have a small operational footprint (e.g. provide a documented, o Have a small operational footprint (e.g. provide a documented,
lightweight mechanism for developers and operators to retrieve the lightweight mechanism for developers and operators to retrieve the
list of PSD DMARC participants) list of PSD DMARC participants)
o Not allow PSDos to add PSDs to the PSD DMARC participants list o Not allow PSO to add PSDs to the PSD DMARC participants list
without third party review without third party review
As of this writing, three approaches have been proposed. None of As of this writing, three approaches have been proposed. None of
them are ideal: them are ideal:
o An IANA registry
o An extension to the Public Suffix List at [PSL] o An extension to the Public Suffix List at [PSL]
o A dedicated registry queried via DNS - an example of such a o A dedicated registry queried via DNS - an example of such a
service is described in Appendix B below service is described in Appendix B.1 below
Appendix B. DMARC PSD Registry Example o An IANA registry
To faciliate experimentation around data leakage mitigation, a sample Appendix B. DMARC PSD Registry Examples
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 To faciliate experimentation around data leakage mitigation, samples
of the DNS based and IANA like registries are available at
[psddmarc.org].
[psddmarc.org] provides a DMARC Public Suffix Domain (PSD) Registry B.1. DMARC PSD DNS Query Service
as a stand-alone DNS query service.
A sample stand-alone DNS query service is available at
[psddmarc.org]. It was developed based on the contents suggested for
an IANA registry in an earlier revision of this draft. Usage of the
service is described on the web site.
B.2. DMARC Public Suffix Domain (PSD) Registry
[psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD)
Registry as a stand-alone DNS query service. It follows the contents
and structure described below. There is a Comma Separated Value
(CSV) version of the listed PSD domains which is suitable for use in
build updates for PSD DMARC capable software.
Names of PSDs participating in PSD DMARC must be registered this new Names of PSDs participating in PSD DMARC must be registered this new
registry. New entries are assigned only for PSDs that require use of registry. New entries are assigned only for PSDs that require use of
DMARC. The requirement has to be documented in a manner that DMARC. The requirement has to be documented in a manner that
satisfies the terms of Expert Review,per [RFC5226]. The Designated satisfies the terms of Expert Review,per [RFC5226]. The Designated
Expert needs to confirm that provided documentation adequately Expert needs to confirm that provided documentation adequately
describes PSD policy to require domain owners to use DMARC or that describes PSD policy to require domain owners to use DMARC or that
all domain owners are part of a single organization with the PSO. all domain owners are part of a single organization with the PSO.
The initial set of entries in this registry is as follows: The initial set of entries in this registry is as follows:
skipping to change at page 10, line 30 skipping to change at page 11, line 15
+-------------+---------------+ +-------------+---------------+
| PSD | Status | | PSD | Status |
+-------------+---------------+ +-------------+---------------+
| .bank | current | | .bank | current |
+-------------+---------------+ +-------------+---------------+
| .insurance | current | | .insurance | current |
+-------------+---------------+ +-------------+---------------+
| .gov.uk | current | | .gov.uk | current |
+-------------+---------------+ +-------------+---------------+
Appendix C. Implementation
There is one known implementation of PSD DMARC available for testing.
C.1. Authheaders Module
The authheaders Python module and command line tool is available for
download or installation from Pypi (Python Packaging Index).
It supports both use of the DNS based query service and download of
the CSV registry file from [psddmarc.org].
Acknowledgements Acknowledgements
Thanks to the following individuals for their contributions (both Thanks to the following individuals for their contributions (both
public and private) to improving this document. Special shout out to public and private) to improving this document. Special shout out to
Dave Crocker for naming the beast. Dave Crocker for naming the beast.
Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen, Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen,
Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig
Schwartz, Alessandro Vesely, and Tim Wicinski Schwartz, Alessandro Vesely, and Tim Wicinski
 End of changes. 19 change blocks. 
32 lines changed or deleted 66 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/