Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

["Murray S. Kucherawy" <[e-mail]>]

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 <[e-mail]> 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