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

Just came in to start WGLC and saw this.  If you have the momentum to do an
update now (like today), feel free.  Otherwise I'll kick off WGLC shortly.

On Mon, Jun 10, 2019 at 3:26 PM Scott Kitterman <sklist@kitterman.com>
wrote:

> On Tuesday, June 4, 2019 6:37:47 PM EDT Tim Draegen wrote:
> > > On May 27, 2019, at 6:59 PM, Scott Kitterman <sklist@kitterman.com>
> wrote:
> > >
> > > On Monday, May 27, 2019 6:53:17 PM EDT internet-drafts@ietf.org 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
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>