I raised objections to the definition of "non-existent", which never received an adequate response before the discussion went silent.
DMARC checks the From header address, which may exist only as an identifier used for mass mailings. These mailings are often sent by an ESP using an unrelated SMTP address. As such, the From address need not be associated with any A, AAAA, or MX record. I assert that the only viable definition of non-existent is "not registered", as evidenced by absence of an NS record. I don't believe the proposed definition of "non-existent" is reliably true even in the special case of interest for this document, impersonation fraud occurring at the top of an organizational structure. Example.PSD may legitimately use mail.Example.PSD for email and www.example.psd for web. If the proposed condition MUST always be true, I have not seen that fact demonstrated. Since the document raises a general concern about fraudulent use of non-existent domains, the definition used should be one that can be generalized., Doug Foster On Tue, Jan 19, 2021 at 1:43 AM Murray S. Kucherawy <[email protected]> wrote: > 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
