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

[Alessandro Vesely <[e-mail]>]

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


+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
--