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

Alessandro Vesely <vesely@tana.it> Fri, 09 November 2018 11:38 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 0290E130DDA for <dmarc@ietfa.amsl.com>; Fri, 9 Nov 2018 03:38:14 -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 UTzlkPG6IDtm for <dmarc@ietfa.amsl.com>; Fri, 9 Nov 2018 03:38:09 -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 EB917130DE9 for <dmarc@ietf.org>; Fri, 9 Nov 2018 03:38:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1541763487; bh=Cwk3tVJlY2DLUDqFC7pyMW3Z1uElJbFT/UyJpIRZ3q8=; l=1650; h=To:References:From:Date:In-Reply-To; b=CMLRytvRy0EV7G7qHwm2gej9Kw3IG9eTplVEYJrsIUuD6pDMhkUbhUTEnG640EA6c RRg2nzzfM027qCLKjL5NBnLUtPkPYWzXSNr43GaGCMoM75YSeT2Hg2t5rrMlCmA7FD U0c1T4UgBANELhr0uiZtAD9c1qroZlOPY4PSK0QS4MWd5m8GANA3NqdA/BBXr
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; Fri, 09 Nov 2018 12:38:07 +0100 id 00000000005DC033.000000005BE5719F.000059FF
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> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> <AB35FEF5-74C9-400D-9A7F-543F9CAA215D@kitterman.com> <CABuGu1pXaXioyPTV6OXD3hWBXVjt5+kk0dqaZwbDcKaU+Y6q5A@mail.gmail.com> <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> <CAL0qLwZF55yaxZKYY8AQdcRfUr2WjMwfpd2FVWn3hCR67_E5eg@mail.gmail.com> <C905829B-3B0E-4DCE-94BD-AC87AD21051A@kitterman.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <86b11f6e-e305-ac07-8408-bdd821ac25a4@tana.it>
Date: Fri, 9 Nov 2018 12:38:06 +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: <C905829B-3B0E-4DCE-94BD-AC87AD21051A@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/P8sx1NgzXupqvVXctT_XfDsogto>
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: Fri, 09 Nov 2018 11:38:14 -0000

On Fri 09/Nov/2018 02:05:04 +0100 Scott Kitterman wrote:
> On November 8, 2018 6:19:38 PM UTC, "Murray S. Kucherawy" wrote:
>> On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely wrote:
>>>
>>> This problem is simpler than DBOUND.
>>>
>>
>> Sure, the DMARC case is half of what DBOUND tried to tackle.  If DBOUND 
>> had focused just on the DMARC use case, it would've succeeded.
"Half of DBOUND" is exact.  Apparently, DBOUND tried to simultaneously solve
both the concept of Organizational domain (which is also related to reputation,
responsibility, and possibly liability) and the concept of establishing a
default, easily overridden policy.  We only need the latter half.

>> [...]
> 
> DBOUND was set up to provide, among other things, a specific input that
> DMARC needs.  The failure of that working group left DMARC with a hole in
> its design.  Operators use the Mozilla PSL as an ad hoc mechanism to fill
> that hole.
By its very nature, PSL defines Organizational domains —the first half.  If you
can exchange session cookies, you share liability.

We don't need to define a topology in the DNS.  We only need a default policy,
established by the parent domain.  Top level TXT RRs can allow some TLD's own
semantics.

DMARC policies also feature reporting addresses.  They are quite different
from, say, the point of contact (POC) linked to IP address space allocations,
but let's note the concept of assigning some responsibility to the entity
owning the first allocation.  So, again, what's wrong with, for example:

_dmarc.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc_stats@verisign.com"

eh?

Best
Ale
--