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 -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
