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

[Scott Kitterman <[e-mail]>]

On Tuesday, June 4, 2019 6:37:47 PM EDT Tim Draegen wrote:
> > 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.

Thanks.  I think those are all good comments.  I can crank out an update or 
wait until after WGLC as the chairs prefer.

Scott K