On Fri 29/Jan/2021 17:21:19 +0100 Kurt Andersen (b) wrote:
On Fri, Jan 29, 2021 at 6:52 AM Tim Wicinski <[email protected]> wrote:
I suggest adding it to this paragraph:
This document specifies experimental updates to the DMARC and PSL
algorithm cited above, in an attempt to mitigate this abuse.
update to DMARC = yes; update to PSL = no
It is difficult to propose changes in OLD:/NEW: format. I attach a patch. It
defers mentioning a PSL until Section 3. That way it may address part of
Dave's objections as well.
On Fri, Jan 29, 2021 at 1:44 AM Murray S. Kucherawy <[email protected]>
wrote:
On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski <[email protected]> wrote:
Since this is an experiment, Appendix A discusses the updates that
happen. we don't actually say explicitly "if the experiment is a success,
the following changes will be made" and perhaps I should add some wording
like that.
Something like this, perhaps?
"A standards track update to [RFC7489] will take into account the results
of this experiment."
... somewhere in Section 1.
A normative dependency from an experimental spec imposed upon a standards
track spec seems like a bad idea to me. At the very least it would impose a
timing constraint that DMARCbis could not be "completed" until after the
PSD experiment is "completed", analyzed and consensus achieved.
This could be weakened by saying "*may* take into account". However, it's not
needed, as the sentence doesn't say *the next* standards track update...
Best
Ale
--
--- draft-ietf-dmarc-psd-tim.xml 2021-01-24 18:50:28.355829817 +0100
+++ draft-ietf-dmarc-psd-ale.xml 2021-01-29 18:58:35.349494946 +0100
@@ -42,14 +42,14 @@
<keyword>TLD</keyword>
<abstract>
- <t>DMARC (Domain-based Message Authentication, Reporting, and
- Conformance) is a scalable mechanism by which a mail-originating
+ <t>Domain-based Message Authentication, Reporting, and
+ Conformance (DMARC) is a scalable mechanism by which a
mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
- organization can use to improve mail handling. The design of DMARC
- presumes that domain names represent either nodes in the tree below
- which registrations occur, or nodes where registrations have occurred;
- it does not permit a domain name to have both of these properties
+ organization can use to improve mail handling.</t>
+ <t>Internet domain names can be represented by a tree. There are nodes
below
+ which registrations occur, and nodes where registrations have
occurred.
+ DMARC does not permit a domain name to have both of these properties
simultaneously. Since its deployment in 2015, use of DMARC has shown
a clear need for the ability to express policy for these domains as
well.</t>
@@ -57,7 +57,7 @@
Suffix Domains (PSDs). This document describes an extension to DMARC
to enable DMARC functionality for PSDs.</t>
<t>This document also seeks to address implementations that consider a
- domain on a public Suffix list to be ineligible for DMARC
+ Public Suffix Domain to be ineligible for DMARC
enforcement.</t>
</abstract>
</front>
@@ -68,42 +68,47 @@
organizational policy information to email receivers. DMARC allows
policy to be
specified for both individual domains and for organizational domains
and their sub-domains within a single organization.</t>
- <t>To determine the organizational domain for a message under 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 found in Section 3.2 of the
DMARC
- specification.</t>
- <t>DMARC as specified presumes that domain names present in a PSL are not
+ <t>Representing Internet domain names in a tree, Public Suffix Domains
(PSD)
+ are those right below or near to the top of the tree, which is the
root.
+ DMARC allows Organizational Domains, which are those right below a PSD,
+ to publish a policy. Subdomains can publish their policy too,
+ overriding the policy of their Organizational Domain. However,
+ PSD currently cannot. In other words,
+ DMARC as specified presumes that PSDs are not
organizational domains and thus not subject to DMARC processing;
domains
are either organizational domains, sub-domains of organizational
- domains, or listed on a PSL. For domains listed in a
- PSL, i.e., TLDs and domains that exist between TLDs and
+ domains, or PSDs. For a
+ PSD, i.e., TLDs and domains that exist between TLDs and
organization level domains, policy can only be published for the
exact domain. No method is available for these domains to express
policy or receive feedback reporting for sub-domains. This missing
method allows for the abuse of non-existent organizational-level
domains and prevents identification of domain abuse in email.</t>
- <t>This document specifies experimental updates to the DMARC and PSL
- algorithm cited above, in an attempt to mitigate this abuse.</t>
+ <t>This document specifies experimental updates to DMARC and to the
+ algorithm to locate Organizational Domains, in an attempt to mitigate
this abuse.
+ A standards track update to <xref target="RFC7489"/> will take
+ into account the results of this experiment.</t>
<section anchor="example" title="Example">
<t>As an example, imagine a country code TLD (ccTLD) which has public
subdomains for government and commercial use (".gov.example" and
- ".com.example"). A PSL whose maintainer is aware of this country's
- domain structurewould include entries for both of these in the PSL,
indicating that they are PSDs below which registrations can occur.
+ ".com.example").
Suppose further that there exists a domain "tax.gov.example",
registered within ".gov.example", that is responsible for taxation
in this imagined country.</t>
- <t>However, by exploiting the typically unauthenticated nature
+ <t>By exploiting the typically unauthenticated nature
of email, there are regular malicious campaigns to impersonate this
organization that use similar-looking ("cousin") domains such as
"t4x.gov.example". Such domains are not registered.</t>
- <t>Within the ".gov.example" public suffix, use of DMARC has been
mandated,
- so "gov.example" publishes the following DMARC DNS record:
+ <t>The domain "gov.example" is a PSD, albeit presumably only qualified
+ organizations can register domains under it. Use of DMARC has
+ been mandated for domains published under it.
+ so "tax.gov.example" publishes the following DMARC DNS record:
<figure><artwork>
_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject; "
"rua=mailto:[email protected]"; )
</artwork></figure>
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 @tax.gov.example. However, due to DMARC's current
method
of discovering and applying policy at the organizational domain
level, the non-existent organizational domain of @t4x.gov.example
does not and cannot fall under a DMARC policy.
@@ -111,7 +116,7 @@
<t> Defensively registering all variants of "tax" is obviously not a
scalable
strategy. The intent of this specification, therefore, is 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 "gov.example", which is
+ determine whether a relevant policy is present at "gov.example",
which is
precluded by the current DMARC algorithm.
</t>
</section>
@@ -153,7 +158,7 @@
effectively Organizational Domains as discussed in <xref
target="RFC7489">DMARC</xref>. They control all
subdomains of the tree. These are effectively private
- domains, but listed in the Public Suffix List. They are
+ domains, but formally they are PSDs, so they are
treated as Public for DMARC
purposes. They require the same protections as DMARC
Organizational Domains, but are currently unable to
@@ -245,6 +250,11 @@
<section title="PSD DMARC Updates to DMARC Requirements">
+ <t>The algorithm DMARC uses to find the Organizational Domain of a
+ given domain hinges on a Public Suffix List (PSL), which is a list
+ of PSDs, possibly making use of wildcards. The process is described
+ in Section 3.2 of the DMARC specification.</t>
+
<t>This document updates DMARC as follows:</t>
<section title="General Updates">
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
