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

[Alessandro Vesely <[e-mail]>]

On Fri 23/Nov/2018 08:20:50 +0100 Scott Kitterman wrote:
> 
> [...]  There's nothing in the draft about walking up a tree.  The draft looks 
> one label higher in the tree than the organizational domain, that's it.  One 
> and only one is the maximum additional number of lookups in the current draft.


That sounds acceptable to me.  I don't think one extra query is going to have a
tremendous impact:

DMARC mechanics entails keeping tracks of A-Rs, indexed by domain, since that
is required for sending aggregate reports.  The availability of such a database
makes it handy to store parsed policies as well.  That is to say, a well
designed mail filter can cache DNS data directly.  Hence, given a decent SOA
TTL, that extra lookup can probably be skipped on most messages.  Compared to
the amount of per-message DNS queries, it doesn't seem to hurt.

DMARC could have a better say on implied TTLs, since data seen at lookup time
is going to be reported at end-of-day time.


> I've no idea how a DNS indication of the boundary would help or hurt these 
> cases, but it's orthogonal to the subject of this message.

Neither do I.

>> 
>> [*] https://ietf.org/blog/herding-dns-camel/
> 
> I'm not sure why you even mention this since the draft proposes no new DNS 
> functionality.


I had read about instructive re-readings of DBOUND in previous discussions on
this subject, so it seemed worth to consider the camel load.


>>> 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.


> 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.


Best
Ale
--