On Thursday, November 22, 2018 06:20:52 PM Alessandro Vesely wrote: > On Wed 21/Nov/2018 08:37:19 +0100 Scott Kitterman wrote: > > [...] > > Also, while I think the discussion about a DMARC specific public boundary > > discovery mechanism was useful, and we should consider taking on that > > work, I think it's not closely coupled to Public Suffix Domains and > > should be discussed as a separate work item. > > /DMARC specific public boundary discovery/ is still ambiguous. Given the > nature of the I-D, we are splitting the concept of boundary into two types: > > 1. *Alignment* which defines sets of shared responsibility, and > > 2. *Policing and reporting* which defines sets of shared criteria. > > Type #1 is a refinement of #2. For example, all banks may wish to share a > secure policy and possibly a common surveillance method. However, they > don't necessarily share customer accounts (let me recall that sharing > session cookies implies just that.)
I'd suggest having the argument about if PSL is good enough or if we need a mechanism in DNS in a separate thread (which is why I wrote another mail to discuss that very topic). There's nothing in this draft about defining where the boundary is (just as in DMARC itself). > > Goals: > > > > 1. Minimize additional verifier burden for adding PSD DMARC support. > > Currently it requires consulting a locally stored, infrequently changing > > list and one additional DNS lookup only for participating public suffixes > > when there is no organizational domain DMARC record. > > Browsing a copy of the PSL, I found just 17 entries with 5 labels, like: > s3.cn-north-1.amazonaws.com.cn and > app.os.stg.fedoraproject.org > > Querying each subdomain would require 4 extra lookups. How much do we save > in a dbound-like scenario? What about organizations that have not yet > published boundary information? How about the camel[*]? No. 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. 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. > > [*] https://ietf.org/blog/herding-dns-camel/ I'm not sure why you even mention this since the draft proposes no new DNS functionality. > > 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]. 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. Scott K [1] https://tools.ietf.org/rfc/rfc7258.txt _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
