Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

"Douglas E. Foster" <fosterd@bayviewphysicians.com> Sun, 22 November 2020 01:32 UTC

Return-Path: <btv1==59501bba465==fosterd@bayviewphysicians.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 D8FD63A0B62 for <dmarc@ietfa.amsl.com>; Sat, 21 Nov 2020 17:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com
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 DnwqGZaBZu1i for <dmarc@ietfa.amsl.com>; Sat, 21 Nov 2020 17:32:18 -0800 (PST)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978D23A0B60 for <dmarc@ietf.org>; Sat, 21 Nov 2020 17:32:18 -0800 (PST)
X-ASG-Debug-ID: 1606008733-11fa313c0128b30001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id wq2wEDVbCmVDx8Vm (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Sat, 21 Nov 2020 20:32:13 -0500 (EST)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=8Ngply0qTZAcGBXTwNLbA5nckqTeOi6alaCeFwfnVuU=; b=SDbhn8KmiiaAlw7rbXR8NNqgbKJAK9bqSzMdbUfM74XpqEwdebHeAh+uF18Kb9y8p fBc2M6zH33kuI73/0zYJZjin+E54Tmg0b6FS58AHHDyqBB6/InYl7nfjmQjQ2Wcok qHsPo9BWAJ60V47OO0ydX2RP4bKv+sooKYGqOEe60=
From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Date: Sat, 21 Nov 2020 20:32:06 -0500
X-ASG-Orig-Subj: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <1331a357df2645b29f326783bd83a697@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="3e7d0500fd8543d893a1b51123d2aa24"
In-Reply-To: <CAL0qLwYgTiHW5XXt3PTUMOiSHV0wUt_fRLyZS7D5v1ZH_WUCNg@mail.gmail.com>
References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> <b6f2bf756f9146daafa717c2645ed58d@bayviewphysicians.com> <CAL0qLwYmRWwLOB7wnPBbChX-fZ3B2xFH5C_Bzh6qLZ9LiTzy5Q@mail.gmail.com> <52963338956e4396b746beccd2f0b78f@bayviewphysicians.com> <CAL0qLwZGbTwnZ8Bk=drM_FA6mZR4KcAHrJB3T93VMobsUGY0Mg@mail.gmail.com> <CAL0qLwYgTiHW5XXt3PTUMOiSHV0wUt_fRLyZS7D5v1ZH_WUCNg@mail.gmail.com>
X-Exim-Id: 1331a357df2645b29f326783bd83a697
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1606008733
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 17136
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86034 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/FrTs2yFjTiepFNkq6uA61TjxCKQ>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
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: Sun, 22 Nov 2020 01:32:21 -0000

I am arguing for the position that all unregistered domains are inherently invalid, because they are not registered.

PSD for DMARC proposes that non-existent domains should be blocked.    In their discussions, I remember the UK government reporting that they had registered 27,000 domains simply so they could publish SPF -ALL, in an attempt to block spammers from spoofing their government agencies.   I have a problem with the definition they chose in their document, but I fully agree that this is a problem that should be fixed.

They have also suggested that their "np" policy has general applicability, an argument which I find compelling.   By "general", I mean non-existent TLDs, non-existent public suffixes below the TLD, non-existent organizations, and non-existent subdomains of organizations.

Their experience demonstrates that an undefined domain is very difficult to protect.
....

On tree walk, I was working from John Levine's proposal, which assumes that a tree walk has to be distance limited for performance reasons.   He tentatively proposed four levels.   If you walk up the tree and find no DMARC entry, the walk stops with the conclusion that no policy has been issued.   This approach works if (and only if) the tree exists, so that the organization can place a policy at every fourth level.   The approach cannot work if the tree can be extended with non-existent domains.    It also conflicts with the PSD proposal which requires checking the top of the tree structure.

I had considered the top-down approach also, for the same reasons as you mentioned.   I assumed that it would be rejected because of the load placed on upper levels of the DNS hierarchy.

But when mulling the PSD problem with the tree-walk problem, I realized the unifying problem in all of these scenarios was unregistered domains.   Eventually the problem became further defined as, "Why should unregistered domains be considered acceptable by default, despite a network-wide requirement for all domains to be registered."

For the moment, it is a DMARC issue to me because DMARC has accepted the notion that unregistered domains are acceptable by default.   If that can be changed, I agree that there are other documents that need to be updated as well.

DF

----------------------------------------

From: "Murray S. Kucherawy" <superuser@gmail.com>
Sent: 11/21/20 8:05 PM
To: Doug Foster <fosterd@bayviewphysicians.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy <superuser@gmail.com> wrote:

On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster <fosterd=40bayviewphysicians.com@dmarc.ietf.org> wrote:

- If unregistered domains are tolerated, PSD for DMARC helps address the problem of a unauthorized domains underneath a public suffix, such as "example.uk".  But what DMARC policy will solve the problem of an invalid TLD, such as "example.q"?

Why is this a DMARC problem that needs solving?

- If unregistered domains are tolerated, then a limited-scope tree walk becomes unusable.   A spammer would be able to  fabricate a few levels of non-existent subdomains, and suddenly PayPal.com becomes a domain tree with no detectable DMARC policy.

You're going to have to give us an example of what you're imagining here.  Presumably fabricating a few levels of non-existent subdomains of paypal.com would look like foo.bar.baz.paypal.com; a simple tree walk then would be to look for records in these places:

foo.bar.baz.paypal.com
bar.baz.paypal.com
baz.paypal.com
paypal.com

I would expect a policy to be present at least at "paypal.com", so the walk stops there.  How is that "unusable"?

Someone in DNSOP, I think, proposed doing the tree walk in the other direction.  The reason: If you're going to get an NXDOMAIN, it is more likely to come earlier, and it's dispositive that way.  For instance, if the above sequence is reversed, you would probably get an NXDOMAIN at the second query ("baz.paypal.com") and then you know you don't need to look any further.

-MSK