Re: [dmarc-ietf] Request to accept a new I-D into the WG work items

[Scott Kitterman <[e-mail]>]

On November 7, 2018 1:42:42 PM UTC, Alessandro Vesely <[e-mail]> 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