In the interests of getting this document on its way, I'd like to suggest the following edits in response to Dale's most recent message. If the working group concurs, we can finally get this out to Last Call.
My goal as an AD here is just to get the GenART feedback addressed, but the text is being submitted as a WG contribution for discussion and consensus consideration, not as a demand. Please process accordingly; I believe the agreement is to do another WGLC on the document before it goes on its way, so the sooner consensus is reached on all of this, the sooner it goes. First, a suggestion of my own that I think I saw elsewhere, but it's not in Dale's reply: In several places there's a reference to "DMARC [RFC7489]". That's appropriate the first time the reference is made, but I think after that you can just say "DMARC" when referring to the protocol generally, or to "RFC 7489" when you need to make a specific section or text reference. They don't need to appear together everywhere. I think Dave's original feedback has been addressed -- good stuff -- so here are my suggestions around what's left: 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. > 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. 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 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." Ignoring that I dislike this use of > "leverage", a critical point is that it takes the existence of public > suffix lists a priori -- indeed, this use of "leverage" generally means > that the leveraged thing already exists and one is now extracting > additional benefit from that. Whereas I've never heard of public suffix > lists and would naively expect that they are difficult to create and > maintain. It might be better to say "DMARC uses public suffix lists to > determine which domains are organizational domains. Public suffix lists > are obtained/maintained/distributed by ..." > 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. 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. 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. 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. 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: 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. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc