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

[Scott Kitterman <[e-mail]>]

On Friday, January 18, 2019 04:14:42 AM Scott Kitterman wrote:
> On Thursday, January 17, 2019 01:50:18 PM John Levine wrote:
> > In article <3104294.rU99Ex2XNH@kitterma-e6430> you write:
> > >My understanding is that, since, as you say, PSOs (like .bank) have a
> > >pre-
> > >existing relationship with their registrants, they don't need PSD DMARC
> > >to
> > >audit their registrant's policies.  For an entity like that, it offers
> > >the
> > >chance to get feedback on other, presumably non-existent, domains so as
> > >to
> > >better understand abuse patterns within the PSD they manage.  It also
> > >gives
> > >them a mechanism to express a reject policy for those domains, which does
> > >not currently exist.  This may help improve rejection of cousin domains
> > >by
> > >receivers.
> > >
> > >For single entity PSDs, like for a very large Internet company that is,
> > >conveniently not named after a large South American rain forest (so they
> > >can get it registered), it offers other advantages.  In cases like this,
> > >the PSD operates like an organizational domain except for the fact that
> > >in
> > >the current DMARC instantiation, their record won't work for subdomains.
> > >PSD DMARC would enable '.example' to publish a single record for all
> > >lower
> > >level entries in the zone.
> > 
> > That all seems reasonable but it still feels like a lot of mechanism for
> > marginial benefit, particularly since we have no clue who's going to run
> > it
> > if we can't foist it off on Mozilla.
> > 
> > I wonder if there's any way to get the PSL to tag vanity TLDs.
> 
> There are two parts to the PSL; a section called "ICANN DOMAINS" and another
> called "PRIVATE DOMAINS".  All the TLDs (single user or not) are in the
> ICANN DOMAINS section.
> 
> I don't know if it would be enough to have them also listed in PRIVATE
> DOMAINS.  I don't expect they would want to remove them from ICANN DOMAINS,
> since that's not wrong, it just doesn't fit out use case.
> 
> It would require some adjustments to the current DMARC algorithm for
> organizational domain identification.
> 
> The current process is to take the 2822.From domain and (assuming there is
> no DMARC record for that domain) look-up in the PSL and reduce the
> 2822.From domain to the PSL ICANN DOMAIN + one level.  If that level has no
> DMARC record, then the domain does not participate in DMARC.
> 
> If Mozilla would add these single user TLDs to the PRIVATE DOMAINS section
> also, we could adjust this slightly and for this use case (which is only one
> of three in the draft) it would work:
> 
> After checking PSL ICANN DOMAIN + one level, if there is no DMARC record,
> then check the PSL PRIVATE DOMAIN list and if the domain is listed there,
> check for a DMARC record.
> 
> I don't know that this would violate the sematics of the PSL and they are,
> in fact, both ICANN domains and private.  Based on the description at
> https://publicsuffix.org/list/ it seems like it might be accepted.
> 
> Regardless of exactly how we do this for PSD DMARC, it is probably work
> documenting that for DMARC (the regular kind), only the ICANN domain section
> of the PSL is used.
> 
> Does anyone know someone at Mozilla to ask?
> 
> For the other, non-single user domains, maybe the best we can do is an
> appendix that describes the characteristics of PSDs for which PSD DMARC
> checks are suitable and lists our three from the initial registry as
> examples. Otherwise, I think we need a new list somewhere because those
> (like .bank) are clearly not private.  If IANA is not the right place to
> host a list, does anyone have any other suggestions for the ones that won't
> work on the PSL?

After some off-list discussion with someone who knew someone who knew about 
PSL, it seems PSL probably isn't the right choice for this (meh).

The current PSL is over 12K lines long.  What we're talking about here is 
probably .1% to 1% that size.  Leaving aside for a moment the mechanism, would 
people review the latest draft and see if they think the privacy issues are 
adequately described and if they require some kind of mitigation?

Scott K