Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

Alessandro Vesely <vesely@tana.it> Sat, 30 March 2024 18: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 817D5C14F68A for <dmarc@ietfa.amsl.com>; Sat, 30 Mar 2024 11:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Level:
X-Spam-Status: No, score=-1.298 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, MANY_SUBDOM=3.099, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqkeCpiiCLjZ for <dmarc@ietfa.amsl.com>; Sat, 30 Mar 2024 11:38:37 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [94.198.96.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9128CC14F684 for <dmarc@ietf.org>; Sat, 30 Mar 2024 11:38:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1711823914; bh=THOFiy0/IjYxFOa1R45hZP4/8ehuZ2a63kmjOyfQaPM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=AhyxccvYpXRkFnwU5rYpfRfomsAGyVHQux2EnksnloOkBT5NM/HEj1RrSzykcDdYr 8LOMO2tK4BJYpfDOIKOR3JdSQ6fT9Kfk5I2Zv8YIimEYVc38aq2yN2PzY0RxdAC4fN ch/IqUEiHmJfV5OJFUPuenZaqZx+ok3BRNvntWeMcr1uY/c3TAkltNKRQpCHF
Original-Subject: Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30
Author: Alessandro Vesely <vesely@tana.it>
Original-Cc: dmarc@ietf.org
Received: from [172.25.197.120] (pcale.tana [::ffff:172.25.197.120]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC192.0000000066085C29.000005DD; Sat, 30 Mar 2024 19:38:33 +0100
Message-ID: <631abdb1-4ae1-469b-8d36-c0212028e5a8@tana.it>
Date: Sat, 30 Mar 2024 19:38:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Jim Fenton <fenton@bluepopcorn.net>
Cc: dmarc@ietf.org
References: <F5158C76-BD86-4540-965D-F0D8664B6CD9@bluepopcorn.net> <b41bdf43-f405-4efa-a227-95884f1921f0@tana.it> <3FCE5958-83E6-473C-AAB1-92690113E0EA@bluepopcorn.net>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
Content-Language: en-US, it-IT
In-Reply-To: <3FCE5958-83E6-473C-AAB1-92690113E0EA@bluepopcorn.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/wyBi84oxK94OD0uoHm4Nw8dGiFA>
Subject: Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 30 Mar 2024 18:38:44 -0000

On Sat 30/Mar/2024 17:56:53 +0100 Jim Fenton wrote:
> On 30 Mar 2024, at 7:43, Alessandro Vesely wrote:
>> On Sat 30/Mar/2024 04:09:10 +0100 Jim Fenton wrote:
>>>
>>> I’m concerned that some (admittedly rare) public suffixes with multiple components are not well served by this algorithm, such as pvt.k12.ma.us.
>>
>> Is there something peculiar with this domain?  Please expand.
> 
> It’s an example that appears on https://publicsuffix.org that I cited because it has many components. I’m not sure there is really a problem with this, though.


No, problems may happen with more than 5 labels.  A psd=y tag at 
1.2.3.4.5.example won't be found if starting the tree walk from a subdomain.


>>> What happens if a domain that is not a public suffix publishes psd=y, either accidentally or maliciously?
>>
>> The interesting point of the Tree Walk is that it allows any domain to self appoint itself as PSO or org domain, without going through PSL bureaucracy.
>>
>> By publishing psd=y, a domain cannot use relaxed alignment, and may prevent some receivers from issuing failure reports.  By not publishing psd=y, a PSO does a disservice to its independent subdomains, forcing them to publish psd=n.
> 
> I didn’t follow all of the DMARC discussion about the tree walk, so I don’t understand the psd tag fully. I understand what the algorithm does with it, but it would be nice if the document described what happens if a PSO fails to publish psd=y or if a non-PSO publishes psd=y. Does the tree walk fail in some way (e.g., fails to find a policy it should) or does it just cause additional DNS lookups?


If someone publishes psd=y, then it /is/ a PSO by definition, at least for 
DMARC purposes.  It may have no (independent) subdomains, so you may say it's 
not a real PSO, but this doesn't badly affect the tree walk.


> At first glance, it seems that a domain that is under a public suffix that doesn’t publish psd=y might be vulnerable to subdomain-exhaustion attacks (a.b.c.d.e.f.g.h.i.j.k.l.example.org if .org doesn’t publish one). It doesn’t seem like a PSO has a particular incentive to publish a record, and there are many public suffixes that would need to be covered.


.org won't have to publish psd=y.  That is for some TLDs like .bank, who 
exercise some kind of control over their affiliates.

The choice of the tag name, psd, is intentionally obscure in an attempt to 
avoid a record update rush.  The tree walk should work well without much DNS 
change.


Best
Ale
--