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