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

"Murray S. Kucherawy" <superuser@gmail.com> Sun, 22 November 2020 01:03 UTC

Return-Path: <superuser@gmail.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 B75CF3A0AA7 for <dmarc@ietfa.amsl.com>; Sat, 21 Nov 2020 17:03:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 vJVHF_AOkCF8 for <dmarc@ietfa.amsl.com>; Sat, 21 Nov 2020 17:03:01 -0800 (PST)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A743A0AA3 for <dmarc@ietf.org>; Sat, 21 Nov 2020 17:03:01 -0800 (PST)
Received: by mail-vs1-xe34.google.com with SMTP id l22so7211175vsa.4 for <dmarc@ietf.org>; Sat, 21 Nov 2020 17:03:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0ds2cDVKNXez6U0Q5krZt5Wj11FyBbSLghWjgN5qvU8=; b=OA4uweujraAu4NvVF9oNJvmkioZCBy2LProvC3+BqbksnDICFzeJnCy5YjuwrcwWV0 6sgeTGYAAjEIu/MjwNx8NYRS8zxlTYXT5jKDjPg/mDQnAUvAJ3FsviG92gQWQTp0owVl oV4mFi2w3Jw+JwsBeCAKbyl2CdiPLE6dPiTKD4AF5nJOLy6BLwsG3tNqivX90fzGWq6Q dCc+kJoPdgj0YsIwmU4OsWfOUpagqlv2tSrqBGdJMy16Lri/CQ0JrPAp/P0e18vn+6AE ucsWbM29mzpdkmh9py42XnDDe05ExDXSsGYJucQaGEN0kA1U47xArDEjgukDJwC/bxq9 pFTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0ds2cDVKNXez6U0Q5krZt5Wj11FyBbSLghWjgN5qvU8=; b=pO0KOlibWJzm9ZPRw+nB5tbT664hioA5r4bVZ7RSEpntPS5zNLQo3/9ulYkZdzDhov GA15FaPzlrA1Wqm6pMSoTPzAQjHz5x1Oo7p4569lffv1Byj+9FNF+mSwRbqTkHvNU/50 dBV/Fu7gDjLI49xBwRR+dNP02USHlXskv8aOSuG0A182a/T526HcsWFxbuMUfh0HFLly CNFwRCo72/BrJEJlAw4t09hkMgBzbB+FHkmYmk2yYDAYrQz3vBpWhLZVHe2YQMVOX/kb 4hfb2AtNLIYK3K3ZJbhgKk5Vh4KgbWlmKT48lL9qCWBas6ocrcY7L47dJe+45QKDId9g eu4w==
X-Gm-Message-State: AOAM531Z3rrtxXpQlS/91Vc2GmLKvd4HOefGA8t30WBCiMKlWLykjsZi VgWO2xJzhRJsKK44y6ZgtB1o7aAwrH+n0CLa43/vjC6ar5I=
X-Google-Smtp-Source: ABdhPJx7w8vA5WpmPRWJIg4I6NzQzktwlimhyCjooqhf5UCcnyHY0J/xwgMhCElMv2LC6384YVOCUFYKBQOYXTC7vY8=
X-Received: by 2002:a67:f1c7:: with SMTP id v7mr1345883vsm.40.1606006980177; Sat, 21 Nov 2020 17:03:00 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <52963338956e4396b746beccd2f0b78f@bayviewphysicians.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sat, 21 Nov 2020 17:02:47 -0800
Message-ID: <CAL0qLwZGbTwnZ8Bk=drM_FA6mZR4KcAHrJB3T93VMobsUGY0Mg@mail.gmail.com>
To: Doug Foster <fosterd@bayviewphysicians.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008f711a05b4a7a3f6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/A4sWewMwE-6ImiFBCQuSdfbOUQg>
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:03:06 -0000

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"?

The PSL mechanism is a heuristic allowing a short-cut from the top one to
the bottom one, so there are only two lookups, based on the PSL which
provides a hint about where to jump after the first query.  But the PSL has
aspects of its management that are not desirable, and the tree walk is an
alternative.

Besides, a scope-limited tree walk conflicts with the requirements of PSD
> for DMARC.
>

Well sure; as I understand it, a tree walk would obviate the need for PSD.

An unlimited-scope tree walk has performance risks to both the evaluator
> and the DNS infrastructure.
>

So the theory goes.  I believe what John is saying is that he's asked the
DNS community, and they no longer think it's a concern, which means we
don't need to worry at least about the latter, and the former is probably
at least partially resolved by caching.

-MSK