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.) > 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[*]? [*] https://ietf.org/blog/herding-dns-camel/ > 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. Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
