draft-ietf-dmarc-psd-11.txt   draft-ietf-dmarc-psd-12.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft fTLD Registry Services Internet-Draft fTLD Registry Services
Intended status: Experimental T. Wicinski, Ed. Intended status: Experimental T. Wicinski, Ed.
Expires: September 20, 2021 March 19, 2021 Expires: October 14, 2021 April 12, 2021
Experimental DMARC Extension For Public Suffix Domains Experimental DMARC Extension For Public Suffix Domains
draft-ietf-dmarc-psd-11 draft-ietf-dmarc-psd-12
Abstract Abstract
Domain-based Message Authentication, Reporting, and Conformance Domain-based Message Authentication, Reporting, and Conformance
(DMARC) permits a domain-controlling organization to express domain- (DMARC) permits a domain-controlling organization to express domain-
level policies and preferences for message validation, disposition, level policies and preferences for message validation, disposition,
and reporting, which a mail-receiving organization can use to improve and reporting, which a mail-receiving organization can use to improve
mail handling. mail handling.
DMARC distinguishes the portion of a name that is a Public Suffix DMARC distinguishes the portion of a name that is a Public Suffix
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 September 20, 2021. This Internet-Draft will expire on October 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 34 skipping to change at page 2, line 34
1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Conventions Used in This Document . . . . . . . . . . . . 5 2.1. Conventions Used in This Document . . . . . . . . . . . . 5
2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5 2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5
2.3. Organizational Domain . . . . . . . . . . . . . . . . . . 6 2.3. Organizational Domain . . . . . . . . . . . . . . . . . . 6
2.4. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . 7
3.2. Changes in Section 6.3 "General Record Format" . . . . . 7 3.2. Changes in Section 6.3 "General Record Format" . . . . . 7
3.3. Changes in Section 6.5 "Domain Owner Actions" . . . . . . 7 3.3. Changes in Section 6.5 "Domain Owner Actions" . . . . . . 7
3.4. Changes in Section 6.6.1 "Extract Author Domain" . . . . 7 3.4. Changes in Section 6.6.1 "Extract Author Domain" . . . . 7
3.5. Changes in Section 6.6.3 "Policy Discovery" . . . . . . . 8 3.5. Changes in Section 6.6.3 "Policy Discovery" . . . . . . . 8
3.6. Changes in Section 7 "DMARC Feedback" . . . . . . . . . . 8 3.6. Changes in Section 7 "DMARC Feedback" . . . . . . . . . . 8
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 8 4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 10 6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. PSD DMARC Privacy Concern Mitigation Experiment . . 12 Appendix A. PSD DMARC Privacy Concern Mitigation Experiment . . 12
Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12 Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12
B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 12 B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 12
B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 12 B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 13
B.3. DMARC PSD PSL Extension . . . . . . . . . . . . . . . . . 13 B.3. DMARC PSD PSL Extension . . . . . . . . . . . . . . . . . 13
Appendix C. Implementations . . . . . . . . . . . . . . . . . . 13 Appendix C. Implementations . . . . . . . . . . . . . . . . . . 13
C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 13 C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 14
C.2. Zdkimfilter Module . . . . . . . . . . . . . . . . . . . 14 C.2. Zdkimfilter Module . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
DMARC ([RFC7489]) provides a mechanism for publishing organizational DMARC ([RFC7489]) provides a mechanism for publishing organizational
policy information to email receivers. DMARC allows policy to be policy information to email receivers. DMARC allows policy to be
specified for both individual domains and for organizational domains specified for both individual domains and for organizational domains
and their sub-domains within a single organization. and their sub-domains within a single organization.
To determine the organizational domain for a message under To determine the organizational domain for a message under
evaluation, and thus where to look for a policy statement, DMARC evaluation, and thus where to look for a policy statement, DMARC
makes use of a Public Suffix List. The process for doing this can be makes use of a public suffix list. The process for doing this can be
found in Section 3.2 of the DMARC specification. found in Section 3.2 of the DMARC specification. Currently the
public suffix list being used is the most common one that is
maintained by the Mozilla Foundation and made public at
http://publicsuffix.org [1].
In the basic DMARC model, PSDs are not organizational domains and are In the basic DMARC model, PSDs are not organizational domains and are
thus not subject to DMARC processing. In DMARC, domains fall into thus not subject to DMARC processing. In DMARC, domains fall into
one of three categories: organizational domains, sub-domains of one of three categories: organizational domains, sub-domains of
organizational domains, or PSDs. A PSD can only publish DMARC policy organizational domains, or PSDs. A PSD can only publish DMARC policy
for itself, and not for any sub-domains under it. In some cases, for itself, and not for any sub-domains under it. In some cases,
this limitation allows for the abuse of non-existent organizational- this limitation allows for the abuse of non-existent organizational-
level domains and hampers identification of domain abuse in email. level domains and hampers identification of domain abuse in email.
This document specifies experimental updates to the DMARC and PSL This document specifies experimental updates to the DMARC
algorithm cited above, in an attempt to mitigate this abuse. specification cited above, in an attempt to mitigate this abuse.
1.1. Example 1.1. Example
As an example, imagine a Top-Level Domain (TLD), ".example", that has As an example, imagine a Top-Level Domain (TLD), ".example", that has
public subdomains for government and commercial use (".gov.example" public subdomains for government and commercial use (".gov.example"
and ".com.example"). The maintainer of a list of such a PSD and ".com.example"). The maintainer of a list of such a PSD
structure would include entries for both of these sub-domains, structure would include entries for both of these sub-domains,
thereby indicating that they are PSDs, below which organizational thereby indicating that they are PSDs, below which organizational
domains can be registered. Suppose further that there exists a domains can be registered. Suppose further that there exists a
legitimate domain called "tax.gov.example", registered within legitimate domain called "tax.gov.example", registered within
".gov.example". ".gov.example".
However, by exploiting the typically unauthenticated nature of email, However, by exploiting the typically unauthenticated nature of email,
there are regular malicious campaigns to impersonate this there are regular malicious campaigns to impersonate this
organization that use similar-looking ("cousin") domains such as organization that use similar-looking ("cousin") domains such as
"t4x.gov.example". Such domains are not registered. "t4x.gov.example". Such domains are not registered.
Within the ".gov.example" public suffix, use of DMARC has been Within the ".gov.example" public suffix, use of DMARC has been
mandated, so "gov.example" publishes the following DMARC DNS record: mandated, so "gov.example" publishes the following DMARC DNS record:
_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject; " _dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject;"
"rua=mailto:dmc@dmarc.svc.gov.example" ) "rua=mailto:dmc@dmarc.svc.gov.example" )
This DMARC record provides policy and a reporting destination for This DMARC record provides policy and a reporting destination for
mail sent from @gov.example. Similarly, "tax.gov.example" will have mail sent from @gov.example. Similarly, "tax.gov.example" will have
a DMARC record that specifies policy for mail sent from addresses a DMARC record that specifies policy for mail sent from addresses
@tax.gov.example. However, due to DMARC's current method of @tax.gov.example. However, due to DMARC's current method of
discovering and applying policy at the organizational domain level, discovering and applying policy at the organizational domain level,
the non-existent organizational domain of @t4x.gov.example does not the non-existent organizational domain of @t4x.gov.example does not
and cannot fall under a DMARC policy. and cannot fall under a DMARC policy.
Defensively registering all variants of "tax" is obviously not a Defensively registering all variants of "tax" is not a scalable
scalable strategy. The intent of this specification, therefore, is strategy. The intent of this specification, therefore, is to enhance
to enhance the DMARC algorithm by enabling an agent receiving such a the DMARC discovery method 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 specification.
1.2. Discussion 1.2. Discussion
This document provides a simple extension to [RFC7489] to allow This document provides a simple extension to [RFC7489] to allow
operators of Public Suffix Domains (PSDs) to: operators of Public Suffix Domains (PSDs) to:
o Express policy at the level of the PSD that covers all o Express policy at the level of the PSD that covers all
organizational domains that do not explicitly publish DMARC organizational domains that do not explicitly publish DMARC
records records
skipping to change at page 5, line 13 skipping to change at page 5, line 15
example@example should be subject to DMARC processing). Testing had example@example should be subject to DMARC processing). Testing had
revealed that this is not consistently applied in different revealed that this is not consistently applied in different
implementations. implementations.
There are two types of Public Suffix Operators (PSOs) for which this There are two types of Public Suffix Operators (PSOs) for which this
extension would be useful and appropriate: extension would be useful and appropriate:
o Branded PSDs (e.g., ".google"): These domains are effectively o Branded PSDs (e.g., ".google"): These domains are effectively
Organizational Domains as discussed in [RFC7489]. They control Organizational Domains as discussed in [RFC7489]. They control
all subdomains of the tree. These are effectively private 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 current public suffix list. They are
as Public for DMARC purposes. They require the same protections treated as Public for DMARC purposes. They require the same
as DMARC Organizational Domains, but are currently unable to protections as DMARC Organizational Domains, but are currently
benefit from DMARC. unable to benefit from DMARC.
o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
Because existing Organizational Domains using this PSD have their Because existing Organizational Domains using this PSD have their
own DMARC policy, the applicability of this extension is for non- own DMARC policy, the applicability of this extension is for non-
existent domains. The extension allows the brand protection existent domains. The extension allows the brand protection
benefits of DMARC to extend to the entire PSD, including cousin benefits of DMARC to extend to the entire PSD, including cousin
domains of registered organizations. domains of registered organizations.
Due to the design of DMARC and the nature of the Internet email Due to the design of DMARC and the nature of the Internet email
architecture [RFC5598], there are interoperability issues associated architecture [RFC5598], there are interoperability issues associated
skipping to change at page 11, line 24 skipping to change at page 11, line 24
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/>.
[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
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 12, line 9 skipping to change at page 12, 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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
7.3. URIs
[1] http://publicsuffix.org
Appendix A. PSD DMARC Privacy Concern Mitigation Experiment Appendix A. PSD DMARC Privacy Concern Mitigation Experiment
The experiment being performed has three different questions which The experiment being performed has three different questions which
are looking to be addressed in this document. are looking to be addressed in this document.
o Section 3.2 modifies policy discovery to add an additional DNS o Section 3.2 modifies policy discovery to add an additional DNS
lookup. To determine if this lookup is useful, PSDs will add lookup. To determine if this lookup is useful, PSDs will add
additional DMARC records in place, and will analyze the DMARC additional DMARC records in place, and will analyze the DMARC
reports. Success will be determined if a consensus of PSDs that reports. Success will be determined if a consensus of PSDs that
publish DMARC records are able to collect useful data. publish DMARC records are able to collect useful data.
skipping to change at page 13, line 8 skipping to change at page 13, line 16
[psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD) [psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD)
Registry as a stand-alone DNS query service. It follows the contents Registry as a stand-alone DNS query service. It follows the contents
and structure described below. There is a Comma Separated Value and structure described below. There is a Comma Separated Value
(CSV) version of the listed PSD domains which is suitable for use in (CSV) version of the listed PSD domains which is suitable for use in
build updates for PSD DMARC capable software. 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 [RFC8126]. 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:
+-------------+---------------+ +-------------+---------------+
| PSD | Status | | PSD | Status |
+-------------+---------------+ +-------------+---------------+
| .bank | current | | .bank | current |
+-------------+---------------+ +-------------+---------------+
| .insurance | current | | .insurance | current |
+-------------+---------------+ +-------------+---------------+
| .gov.uk | current | | .gov.uk | current |
+-------------+---------------+ +-------------+---------------+
| .mil | current | | .mil | current |
+-------------+---------------+ +-------------+---------------+
B.3. DMARC PSD PSL Extension B.3. DMARC PSD PSL Extension
[psddmarc.org] provides a PSL like file to enable to facilitate [psddmarc.org] provides a file formatted like the Public Suffix List
identification of PSD DMARC participants. Contents are functionally (PSL) in order to facilitate identification of PSD DMARC
identical to the IANA like registry, but presented in a different participants. Contents are functionally identical to the IANA like
format. registry, but presented in a different format.
When using this approach, the input domain of the extension lookup is When using this approach, the input domain of the extension lookup is
supposed to be the output domain of the regular PSL lookup, i.e. the supposed to be the output domain of the regular PSL lookup, i.e. the
organizational domain. This alternative data approach is potentially organizational domain. This alternative data approach is potentially
useful since DMARC implementations already need to be able to parse useful since DMARC implementations already need to be able to parse
the data format, so it should be easier to implement. the data format, so it should be easier to implement.
Appendix C. Implementations Appendix C. Implementations
There are two known implementations of PSD DMARC available for There are two known implementations of PSD DMARC available for
skipping to change at page 14, line 12 skipping to change at page 14, line 20
It supports both use of the DNS based query service and download of It supports both use of the DNS based query service and download of
the CSV registry file from [psddmarc.org]. the CSV registry file from [psddmarc.org].
C.2. Zdkimfilter Module C.2. Zdkimfilter Module
The zdkimfilter module is a separately available add-on to Courier- The zdkimfilter module is a separately available add-on to Courier-
MTA. MTA.
Mostly used for DKIM signing, it can be configured to also verify, Mostly used for DKIM signing, it can be configured to also verify,
apply DMARC policies, and send aggregate reports. For PSD DMARC it apply DMARC policies, and send aggregate reports. For PSD DMARC it
uses the PSL extension list approach, which is available from from uses the PSL extension list approach, which is available from
[psddmarc.org] [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
 End of changes. 20 change blocks. 
32 lines changed or deleted 39 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/