On Tue 06/Nov/2018 20:39:14 +0100 Scott Kitterman wrote: > On November 6, 2018 7:17:10 PM UTC, Alessandro Vesely wrote: >> >> At a first glance, it seems an attempt to override the Public Suffix List >> with a IANA registry. The PSL is based on IANA root zones, taking into >> account PSO policies. So, we're requiring PSOs to register their email >> policies at IANA, while their web policies will continue to be >> "registered" at PSL. Does that sound somewhat curious or is it me?> > Only in a very limited sense. DMARC currently stops at the organizational > domain. This sets up processing and structure for the limited cases where > DMARC 'above' the organizational domain makes sense. I appreciate DMARC's concept of "Organizational domain", which is central for alignment (and reputation tracking, although the latter is unspecified). This is Section 3.2 of rfc7489, where the Public Suffix List is introduced.
However, I'm not clear what security concerns, if any, are implied in Section 6.6.3. For the web case —the Storage Model of rfc6265— the PSL is necessary to avoid session fixation attacks. Rfc7849 is rather worried by the opposite concern, _sub_domains which send evil mail in order to disrupt the reputation of a parent domain (Section 10.4). How can a parent domain attack a subdomain using an evil policy? > To pick one notional example (real domains, but not reflective of any > knowledge of domain owner plans or policies):> > Why shouldn't Google be able to assert DMARC policy over subdomains of > .google the same way it does over .google.com? Currently they can't and > this draft provides policy and mechanism for them to do so if they want. And what's wrong if Verisign publish a _dmarc.com record? Section 6.6.3 of DMARC is meant to avoid too many DNS queries or are there security issues to worry about? Which ones? > Does that clarify it for you? Only in part. If the I-D must involve a IANA registry, I'm opposed. If the intent is to refine policy discovery algorithms otherwise, possibly in general, then I'm wholly in favor. Best Ale _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
