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

[Tim Wicinski <[e-mail]>]

On Tue, Jan 19, 2021 at 1:43 AM Murray S. Kucherawy <[e-mail]>
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 <[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.
>
>
Done

>
> 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]
>
>
done

> 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.
>
>
Done

I also changed the title to "Experimental DMARC Extension for Public Suffix
Domains"

I need to go over the next batch.

I have the XML in my repo:
https://github.com/moonshiner/draft-ietf-dmarc-psd/
and will send a pull request when i've gone back over things.

I do attach the rfcdiff I created locally for folks.  that may help

big thanks Murray