Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.txt

[Tim Draegen <[e-mail]>]

> On May 27, 2019, at 6:59 PM, Scott Kitterman <[e-mail]> wrote:
> 
> On Monday, May 27, 2019 6:53:17 PM EDT [e-mail] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Domain-based Message
>> Authentication, Reporting & Conformance WG of the IETF.
>> 
>>        Title           : DMARC (Domain-based Message Authentication,
>> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)
>> Author          : Scott Kitterman
>> 	Filename        : draft-ietf-dmarc-psd-04.txt
>> 	Pages           : 11
>> 	Date            : 2019-05-27
> 
> There isn't much to this update.  It corrects one typo and reverts the RUF 
> MUST NOT as discussed on the list.  As far as I'm aware there are no other 
> pending issues in the WG with the draft.

Hi Scott, I've reviewed the doc and have made some comments. Feel free to dispose of them as you will.

I had a hard time with the introduction. "sets of domains within a single organization" and "lower level policy" left me not knowing what I was reading. I'm unhappy just complaining, so I took a stab at this admittedly difficult section. The original:

   DMARC [RFC7489] provides a mechanism for publishing organizational
   policy information to email receivers.  DMARC [RFC7489] allows policy
   to be specified for both individual domains and sets of domains
   within a single organization.  For domains above the organizational
   level in the DNS tree, policy can only be published for the exact
   domain.  There is no method available to such domains to express
   lower level policy or receive feedback reporting for sets of domains.
   This prevents policy application to non-existent domains and
   identification of domain abuse in email, which can be important for
   brand and consumer protection.

My stab:

   DMARC [RFC7489] provides a mechanism for publishing organizational
   policy information to email receivers.  DMARC [RFC7489] allows policy
   to be specified for both individual domains and for organizational
   domains and their sub-domains
   within a single organization.  For 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 such 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.


The example section doesn't read like the rest of the draft and was hard for me to read through. Original:

   This would provide policy and feedback for mail sent from
   @gov.example, but not @tax.gov.example and there is no way to publish
   an organizational level policy that would do so.  While, in theory,
   receivers could reject mail from non-existent domains, not all
   receivers do so.  Non-existence of the sending domain can be a factor
   in a mail delivery decision, but is not generally treated as
   definitive on its own.

Again my stab:

   This DMARC record provides policy and a reporting destination for mail sent from
   @gov.example. However, due to DMARC's current method of discovering and applying
   policy at the organizational domain level, the non-existent organizational domain of @tax.gov.example
   does not and cannot fall under a DMARC policy.


I don't have too much more, I just got just caught up in the initial read. This paragraph contains a construct that was confusing to me:

   This memo provides a simple extension to DMARC [RFC7489] to allow
   operators of Public Suffix Domains (PSDs) to express policy for
   groups of subdomains, extends the DMARC [RFC7489] policy query
   functionality to detect and process such a policy, describes receiver
   feedback for such policies, and provides controls to mitigate
   potential privacy considerations associated with this extension.

^^^ why "groups of subdomains" and not just "subdomains"? One step further, why not "express policy at the level of the PSD that covers all organizational domains that do not explicitly publish DMARC records"?


OK, two more things:

2.3.  Longest PSD

   Organizational Domain (DMARC [RFC7489] Section 3.2) with one label
   removed.

^^^ "one left-most label removed"?


Last thing: Security considerations might call out DNS cache poisoning as a way to get reports for a PSD. Applies to vanilla DMARC too, but the scope and potential breadth of information with PSD-DMARC is really interesting. I imagine an attack that gets .COM listed into the PSD Registry for a specific report generator.. combined with cache poisoning and the poor report generator would probably explode at best.