Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains

[Scott Kitterman <[e-mail]>]

On Friday, November 23, 2018 01:17:41 PM Alessandro Vesely wrote:
> On Fri 23/Nov/2018 08:20:50 +0100 Scott Kitterman wrote:
... 
> >>> 2.  Externalize signaling about PSD participation.  As discussed in the
> >>> Privacy Considerations (section 4.1), we were concerned about the
> >>> privacy
> >>> implications of feedback on organizational domain traffic for
> >>> organizational domains that don't participate in DMARC being
> >>> inappropriately captured by public suffix operators.  In order to avoid
> >>> this, we identified criteria for which public suffixes PSD DMARC would
> >>> be
> >>> appropriate for and require an external review to ensure those criteria
> >>> are met.  No solution that's in DNS will address this part of the
> >>> problem.
> >> 
> >> I'm not clear what kind of inappropriateness is implied here.  The
> >> overwhelming majority of people is pretty comfortable with having their
> >> personal stuff stored in "Echelon".  Yet, if a domain is uncomfortable
> >> with
> >> the policy in _dmarc.com, it can opt out by publishing its own record.
> > 
> > That's exactly backwards and the reason I wrote the privacy
> > considerations.
> > It's also completely contrary to IETF policy on the subject, see RFC
> > 7258/BCP 188 [1].
> 
> Agreed.  Rfc7489 misses an analysis of the risk implied by feedback reports,
> except for mentioning that ruf targets receive more privacy-sensible data
> than rua's (Section 12.5).  Your I-D discourages ruf tags in PSD DMARC
> records, so that's partly addressed.
> 
> Your I-D says some PSDs can impose a default DMARC policy while others
> cannot, but doesn't mention a rule to tell which is which.  Yes, it
> mentions a IANA registry, but then it is not clear what rules or principles
> the designated expert would consider adequate.  The case that all domain
> owners are part of a single organization with the PSO would rather seem to
> be an error of the PSL.

The problem is that there is no generic rule to cover all cases, ccTLDs, 
generic TLDs, and legacy TLDs all have different rules (and different rules 
within each of those groups).  That's why we designate an expert to figure it 
out.  Typically (as far as I can tell) RFCs that use designated experts for 
IANA registry review only give very general guidance.  The guidance here is, I 
think, appropriate (DMARC use is required for private domains registered in 
the PSD/TLD).

Arguing the PSL is wrong, isn't really helpful for this use case.  Even if the 
PSL were fixed/replaced by some dbound type thing, that would only affect the 
single use TLD case (so we delete a handful of lines from the draft).  They 
are the simplest case.

I think we should focus on the mechanism to allow for "above org level" DMARC 
checks (which is what this draft does) that is limited in scope so that 
registrars can't conduct an inappropriate land grab.  It's not like this kind 
of thing hasn't happened before [1].

[1] https://www.theregister.co.uk/2003/09/16/all_your_web_typos/


> > During the adoption discussions there was some concern with the registry
> > approach used so far.  I would really like to have a discussion on
> > alternatives.  Personally, I don't think it's very useful to spend working
> > group time on if privacy matters.
> 
> Right, the consensus is that privacy matters.  In rfc7258's words, we need
> to have a good answer to the question "Is pervasive monitoring relevant to
> this work and if so, how has it been considered?"  Unless we do the same
> for all PSDs, a good answer should also explain PSDs differences a little
> bit better than the current I-D does, which seems to be another hairy
> question.

I am open to suggestions.

Scott K