On November 7, 2018 1:42:42 PM UTC, Alessandro Vesely <ves...@tana.it> wrote: >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. > The registry is meant to be a solution to the 'what about .com' problem you mention. It's a solution, not necessarily the best or only one.
I'd suggest we adopt the draft/work item and then try to figure it out. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
