Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts

Alessandro Vesely <vesely@tana.it> Fri, 20 November 2020 09:31 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 A69773A1566 for <dmarc@ietfa.amsl.com>; Fri, 20 Nov 2020 01:31:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 hbW2MJONhefH for <dmarc@ietfa.amsl.com>; Fri, 20 Nov 2020 01:31:07 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58343A1B04 for <dmarc@ietf.org>; Fri, 20 Nov 2020 01:31:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605864665; bh=HlEvRhdtH5XqJYd8McgS4hCZgceEGXjC16y6kGW1BHc=; l=3954; h=To:References:From:Date:In-Reply-To; b=CjeMolY28a5CBAiIWyH2YuG8ki6k4rUS0pNLfLna4iTJ9Xf3h7Fa+/LTNYPZwyriy C+O/Ms6/g+q1FML5c/ErkbvDqrtvbjsSeP3OUhlJJodNsxEu0/ppiw9pY3C3bo1hNd IrPv2pR1u1gquahfzM60zDDAHJQEDUahbrTpJlPIxbdJzOIXSuUy7Ctj72gCz
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005FB78CD9.000021FF; Fri, 20 Nov 2020 10:31:05 +0100
To: dmarc@ietf.org
References: <20201118204436.5BE81278D997@ary.qy> <2cabc3c3-3f72-f3f8-0909-860112d25141@dcrocker.net> <a166ad22-8229-9662-f480-9953607df88d@taugh.com> <fab8a341-dde0-31b9-c770-3029e76d43fb@tana.it> <CAHej_8kfimLTf_iJnPTEC-aE9a7-h7M1bY7vPL7u5J=cAeGPqg@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <ea4fc38d-dab8-4c79-4318-71c53497e72c@tana.it>
Date: Fri, 20 Nov 2020 10:31:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CAHej_8kfimLTf_iJnPTEC-aE9a7-h7M1bY7vPL7u5J=cAeGPqg@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/HfcE4GA7eTlli6K37bnERi1Woy8>
Subject: Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts
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, 20 Nov 2020 09:31:12 -0000

On 19/11/2020 21:33, Todd Herr wrote:
> On Thu, Nov 19, 2020 at 7:39 AM Alessandro Vesely <vesely@tana.it> wrote:
>> On 18/11/2020 22:33, John R Levine wrote:
>>>> On 11/18/2020 12:44 PM, John Levine wrote:
>>>>> so I encourage the group to limit the debate to the existing Org/PSL
>>>>> kludge and a tree walk.
>>>>
>>>> "and a tree walk" is not a minor 'and'.  neither conceptually nor
>>>> operationally.  assurances to the contrary notwithstanding.
>>>
>>> I didn't say they were equivalent.  But I do think they are the only
>>> options that are likely to get much interest from the WG. >>
>> I don't think tree walk is a viable option, as it distorts semantics.
>>
> Forgive me, but I don't know what you mean by the phrase "distorts
> semantics"; can you please help me understand?


The current semantics considers an Organizational Domain to be the expression 
of the organization itself, the organization's master domain.  That's quite 
nearly what the PSL strive for.

Tree walk, instead, discards any organizational boundary.


> As for the viability of a tree walk, it is possible in complex environments
> to have something resembling the following:
> 
>     - RFC5322.From domain - a.b.foo.com - _dmarc.a.b.foo.com non-existent
>     - _dmarc.b.foo.com record exists, p=x, rua=r1
>     - _dmarc.foo.com record exists, p=y, rua=r2
       - _dmarc.com record doesn't exist, for the time being.


> On the other hand, one might infer from the DNS records that are published
> that their intent was for a.b.foo.com to inherit x for the policy and r1 as
> the destination for aggregate reports from the b.foo.com record; this would
> be an error on their part, because DMARC does not currently support
> discovery of the record at _dmarc.b.foo.com in this case.


Without asking them directly, we could also infer that folks at b.foo.com are 
sneakily trying to divert feedback traffic.


> The way I see it, we can choose one of three paths here:
> 
>     1. Keep things as they are, where if there is no policy published for
>     RFC5322.From, the policy is inherited from the org domain, if a policy is
>     published there


Easiest and safest option.


>     2. Change the spec so that the only policy lookup done is for the
>     RFC5322.From domain, and if there's no policy there, then DMARC doesn't
>     exist for that domain


SPF experience shows that large domains don't have the ability to maintain a 
script that defines suitable DNS records for all their subdomains.  This would 
force inconsistent usage of '*' domains.  BTW, as of your example, we have:

ale@pcale:~$ dig _dmarc.b.foo.com txt

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> _dmarc.b.foo.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44418
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ab33c1fc9c9860b18b1294575fb788126f7a88216eadcab7 (good)
;; QUESTION SECTION:
;_dmarc.b.foo.com.		IN	TXT

;; ANSWER SECTION:
_dmarc.b.foo.com.	600	IN	TXT	"v=spf1 -all"

;; AUTHORITY SECTION:
foo.com.		250	IN	NS	ns2.digimedia.com.
foo.com.		250	IN	NS	ns1.digimedia.com.

;; ADDITIONAL SECTION:
ns1.digimedia.com.	172450	IN	A	23.21.242.88
ns2.digimedia.com.	172450	IN	A	23.21.243.119


>     3. Change the spec so that policies published between the RFC5322.From
>     domain and the organizational domain can be discovered, in order to support
>     the most flexibility across organizations.


Besides making a lot of confusion about where policies and feedback addresses 
might come from, this feature inflates DNS queries more than it is desirable. 
If you have From: DoS <ugh@a.b.c.dc.d. ... x.y.z> you have to look up each 
subdomain in the required order.  (Maybe you can check if z exists, and in case 
if m.n.o. ... x.y.z exists, and so on in a dichotomic anti-DoS tactic.  Hm...)


Best
Ale
--