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

Alessandro Vesely <vesely@tana.it> Wed, 07 November 2018 13:42 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2444C12D4EA for <dmarc@ietfa.amsl.com>; Wed, 7 Nov 2018 05:42:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3Br0ZKZzTGh for <dmarc@ietfa.amsl.com>; Wed, 7 Nov 2018 05:42:44 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABBE1274D0 for <dmarc@ietf.org>; Wed, 7 Nov 2018 05:42:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1541598162; bh=ppLofrSjKN8r0nt6+D4K91qQkwQ8q3+xkZD7sekj9oQ=; l=2126; h=To:References:From:Date:In-Reply-To; b=A5I9HSkZdHexiefwkaFD4t2D5CwqUn3J0VT1LTYTcTdS2MUjuCOYdyGCsbkfcXv9z fYQ/5EkYQQ6Hh71ckDvh364DVjO36hWvfeI2FOHrEHbbKYybYU1s2/EER2nxlO7qaw J5vq0gtSLhwS5gMs2Kuur6/i4b8vMCz5cGtz7KuFBBShQNu4Mo8DC2ebYIkrQ
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 07 Nov 2018 14:42:42 +0100 id 00000000005DC033.000000005BE2EBD2.000016D0
To: dmarc@ietf.org
References: <CABuGu1o4E-Svt9N++RaFvO4SATt3Wh1w7gZb1OdBSVRCm7Odmg@mail.gmail.com> <CAC4RtVCQmV5agORght0XWr27kDD+OkaEZcKcaDtE8wLG0Yi-YA@mail.gmail.com> <dee0fd86-40e3-e01d-6c70-2f467759be8b@tana.it> <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it>
Date: Wed, 07 Nov 2018 14:42:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/J7lcMEHhy6lf0Gxi9AEnlLmujxo>
Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 13:42:46 -0000

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