On Tue 19/Jan/2021 07:43:01 +0100 Murray S. Kucherawy wrote:
[...]
On Mon, Nov 16, 2020 at 7:16 PM Dale R. Worley <wor...@ariadne.com> wrote:
My apologies for not tending to this promptly.
In regard to the description of the experiments, the result criteria are
rather subjective, but I don't see that as a problem. It does seem to
me that the title "PSD DMARC Privacy Concern Mitigation Experiment" is
too narrow, as only the 3rd experiment seems to be about privacy
issues. A title as generic as "PSD DMARC Experiments" would be fine.
That's OK with me, or "DMARC PSD Experiments" or "DMARC PSD Experiment" if
we want to treat it all as one common thing.
+1
Although I note that even the -09 does not define "PSD", only "longest
PSD", even though "PSD" is used in section 2.5. I suspect that PSD is
equal to "PSO Controlled Domain Name", though, or rather to some related
set of them. That needs to be cleaned up in some way.
PSD appears to be well defined in Section 2.2.
+1
In section 3.5 and later there is the phrase "[this document] longest
PSD". I'm not sure, but I think this is supposed to be "longest PSD
([this document] section NN.NN)".
Agreed.
I guess "[this document]" refers to the RFC number to be. I think it's useless
and can be safely removed, all of the five occurrences of it.
It is clearer and more useful to specify the referred document when it is /not/
this document. For example:
Changes in Section 6.5 of RFC 7489 "Domain Owner Actions"
The above is going to be rendered with the correct anchor in the htmlized
version of the document. It can be expressed in xml as:
<xref target="RFC7489" sectionFormat="of" section="6.5"/>
so as to generate correct links whenever possible.
I believe that my strongest critique was that section 1 is difficult to
understand if one does not already understand DMARC, and it does not
seem that the section has been revised. Re-reading it, I notice that it
says "DMARC leverages public suffix lists to determine which domains are
organizational domains." [...]
In fact, those are the two terms appearing in the title. BTW, I'd change the
title to:
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Extension For Public Suffix Domains (PSDs)
Anyway, I agree it is correct to introduce /both/ terms.
Replace all of Section 1 with this (ignore funny line wrapping):
DMARC [RFC7489 <https://tools.ietf.org/html/rfc7489>] provides a
mechanism for publishing 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.
+1 to break the paragraph here.
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.
Couldn't we skip that kind of functional intro and say something general, such
as anticipating Section 2.2:
Public Suffix Domains (PSDs) are domain names publicly accessible for
domain registration. As explained in Section 2.2, they include all top
level domains and some more. The way delegations occur on the global
Internet makes it difficult to establish whether a domain is a PSD. A
community maintained Public Suffix List (PSL) exists for that purpose.
Thinking twice, perhaps we don't need to introduce the PSL until Section 3.4.
In that case, strike the last two sentences of the above paragraph.
DMARC as specified presumes that domain names present in a PSL 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
organization level domains, policy can only be published for the
exact domain.
That's still overly specific for an introduction. It only serves to present
the concept that there are domains that are not actually organizational domains
but are characterized by a sort of organizational flavor. The "these domains"
of the following sentence. We don't need seven lines of text for that.
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.
This document specifies experimental updates to the DMARC and PSL
algorithm cited above, in an attempt to mitigate this abuse.
If the PSL is not yet introduced:
This document specifies experimental updates to DMARC and its policy
discovery, in an attempt to mitigate this abuse.
Looking at the second paragraph of section 1, I notice that despite all
the special terms for classifying domain names in section 2, the example
in this section does not describe which of the domain names that it
mentions fall into which of these classes. E.g. "tax.gov.example" is
said to be registered, but it looks like it is also the organizational
domain, and "gov.example" is its longest PSD. It would also help to
mention that "tax.gov.example" is "registered at" "gov.example" to
introduce the details of the usage "registered at".
Suppose there exists a domain "tax.gov.example" (registered at
"gov.example") ...
Introduce a new Section 1.1: "Example" with this:
I don't fully agree. The example only lasts until the end of page 3. From
page 4 on, the text describes the core of the experiment, so it shouldn't be
under an "Example" heading. If we skip the PSL, the example remains quite
compact even after adding those "registered at".
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 structure
would include entries for both of these in the PSL, indicating that they are
PSDs below which registrations can occur. Suppose further that
there exists a domain
"tax.gov.example", registered within ".gov.example", that is
responsible for taxation in this imagined
country.
However, 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.
Within the
".gov.example" public suffix, use of DMARC has been mandated, so
"gov.example" publishes the following DMARC DNS record:
[remainder of -09's page 3, the example, unchanged]
Introduce a new Section 1.2: "Discussion" comprising the remainder of
-09's Section 1. In the first paragraph, between "simple" and
"extension", add "experimental".
A suggestion for 2.4:
NEW:
The longest PSD is the Organizational Domain with one label removed.
It names the immediate parent node of the Organizational Domain in the
DNS namespace tree.
s/one/the leftmost/
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
