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

Scott Kitterman <sklist@kitterman.com> Wed, 07 November 2018 14:42 UTC

Return-Path: <sklist@kitterman.com>
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 D143E130DDF for <dmarc@ietfa.amsl.com>; Wed, 7 Nov 2018 06:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=kQCcxTXT; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Alc0Ogpy
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 5LxdJU3gmUGO for <dmarc@ietfa.amsl.com>; Wed, 7 Nov 2018 06:42:11 -0800 (PST)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84688130DD6 for <dmarc@ietf.org>; Wed, 7 Nov 2018 06:42:11 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541601729; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=JzrWEhbiLSLtXToglCzcUem92uwGTIhqc6SEwTqxtyE=; b=kQCcxTXTMBNfrAFesHe12WmhVO1IpG+/eTxsXs/HcHX6PmOy85sfAZEc guR9dbyGcQ+jeVbC4SnSZsshCtzqAw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541601729; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=JzrWEhbiLSLtXToglCzcUem92uwGTIhqc6SEwTqxtyE=; b=Alc0Ogpyjx6jaIrn/sIjkdpDcFINLz1VjBJ1e9IAJZLPwdfQ3bMcrGrg iskqGU8u0a4T7hLLUbogNPvVCHdMgCRGT4KYSuLv19N7+HCb5RRoZ72Zew asmP0kIufKUKDUwiv3N5X/FC/+g2OSvq8cKnfZF3fHDptulZVJynFRGDDH CVYAqAzK1IgNgQole282CDZZkKgt4pWsdvT3VtuT1g/TJ//VvEgTHCa+bi s6OYLVDf9VbYPF64/r8oJlXGOYgl6Dl7JPcNpA9vCRpTerYzrPtAMdCc69 a3IboYP8hrKC8oIQDcipJDEerdzZaXiKgtQwNlsPLrzmFrFQeIiHbQ==
Received: from [10.75.181.187] (mobile-166-170-32-1.mycingular.net [166.170.32.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4DBCCC400F8; Wed, 7 Nov 2018 08:42:09 -0600 (CST)
Date: Wed, 07 Nov 2018 14:41:25 +0000
In-Reply-To: <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it>
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> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org,Alessandro Vesely <vesely@tana.it>
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <AB35FEF5-74C9-400D-9A7F-543F9CAA215D@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/s6WFe82mpqmFwhZen0iGczyjO0s>
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 14:42:14 -0000


On November 7, 2018 1:42:42 PM UTC, Alessandro Vesely <vesely@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