Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

Scott Kitterman <sklist@kitterman.com> Fri, 10 April 2020 13:49 UTC

Return-Path: <sklist@kitterman.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 4FE353A0AE2 for <dmarc@ietfa.amsl.com>; Fri, 10 Apr 2020 06:49:28 -0700 (PDT)
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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=NScqng3A; dkim=pass (2048-bit key) header.d=kitterman.com header.b=mplnyRa5
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 iLy38azMoH2N for <dmarc@ietfa.amsl.com>; Fri, 10 Apr 2020 06:49:26 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927AA3A0ADE for <dmarc@ietf.org>; Fri, 10 Apr 2020 06:49:26 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 212DEF80272 for <dmarc@ietf.org>; Fri, 10 Apr 2020 09:49:25 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1586526565; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=fn347Itap1GS3w/xs8uYRYWcht5QN2umpnc6BBVI2Ao=; b=NScqng3AzfYmxARuGw3AKEZb2crKV1EnLW5aaG6+EeoWP46McW6DuMZHe+nyFr82dOIYb IDuiSSDDlzDrTveAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1586526565; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=fn347Itap1GS3w/xs8uYRYWcht5QN2umpnc6BBVI2Ao=; b=mplnyRa5q2pJ8A2hbIezC80vqrnktuoJVKJCcsDW7bMbfaMO7p8DK1G6kQAKDkOydvg8X ns75KUYa2B8Ebk350vc0mHe4IPeqOTvdkm1Tm0p6oqb3wZ3JVyRidWScOxZ4qMzp5I2oXN3 vrSkmFps3KagQLdy2otQ1/tsT2CuIKZlBvjakjaXpJTghnPR3SV8d0WEKDQYWHH8MrvCk63 CLUUVT/0N87C/909SFr68v2MKIL0mvASRmaXR6BOomw3M0wYIkgOg8UN7gDe2pTQmfGoEdt Q61VmXeuUE3fgWxBHsOMPEkLfZLSynsBsJeCBVu58oJGFtgc7ky6sKWT2e4w==
Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id E7CF4F801E9 for <dmarc@ietf.org>; Fri, 10 Apr 2020 09:49:24 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Fri, 10 Apr 2020 09:49:24 -0400
Message-ID: <3377169.EuQdDTRyQv@sk-desktop>
In-Reply-To: <CA+Wg=gsS0U-cW8TAFhJw9yQrCP7K-8gjGGDhg1sighiBc5JrgQ@mail.gmail.com>
References: <CABuGu1rekWo3mRkK_OpRksYNrSmPaFHD6k1_K=a7a_Sx7aMhBQ@mail.gmail.com> <20200409230933.E0CBD17638B4@ary.qy> <CA+Wg=gsS0U-cW8TAFhJw9yQrCP7K-8gjGGDhg1sighiBc5JrgQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/9CY0BWxwRWoGV_IouqZH90URjfE>
Subject: Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08
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, 10 Apr 2020 13:49:28 -0000

On Friday, April 10, 2020 9:38:40 AM EDT Todd Herr wrote:
> On Thu, Apr 9, 2020 at 7:09 PM John Levine <johnl@taugh.com> wrote:
> > In article <CABuGu1rekWo3mRkK_OpRksYNrSmPaFHD6k1_K=
> > 
> > a7a_Sx7aMhBQ@mail.gmail.com> you write:
> > >   1. ".co.uk" is not a TLD. TLDs are single label domains - there are
> > >   ccTLDs and gTLDs.
> > 
> > Right.
> 
> I don't disagree, but what I was going for here was some level of
> consistency with section 3.2 of RFC 7489, which reads in part:
> 
>    1.  Acquire a "public suffix" list, i.e., a list of DNS domain names
>        reserved for registrations.  Some country Top-Level Domains
>        (TLDs) make specific registration requirements, e.g., the United
>        Kingdom places company registrations under ".co.uk"; other TLDs
>        such as ".com" appear in the IANA registry of top-level DNS
>        domains.  A public suffix list is the union of all of these.
>        Appendix A.6.1
> <https://tools.ietf.org/html/rfc7489#appendix-A.6.1> contains some
> discussion about obtaining a public
>        suffix list.
> 
> 
> The point of the paragraph in question wasn't to define TLDs (or PSDs) but
> rather to better define "domain names reserved for registration".
> 
> > >   2. The invocation of the PSL compounds the issue that was raised by
> > 
> > Dave
> > 
> > >   Crocker. How DMARC (RFC 7489) determines the organizational domain is
> > >   orthogonal to this proposal which simply calls for a conditional
> > 
> > additional
> > 
> > >   check at the "org - 1" level. I recommend striking the penultimate
> > >   paragraph in the proposal.
> > 
> > I'd suggest weasel wording it to say that the domain above an org
> > domain is often known as a public suffix domain, which typically
> > delegates the org domains below it to a unrelated parties.  This spec
> > allows public suffix domains to publish policies to supplant those of
> > their child org domains ...
> > 
> > I agree we should stay as far from mentioning the PSL and its specific
> > implementation as possible.  Who knows, someday people might get
> > around to trying my dbound in DNS implementation instead.
> 
> Dale twice in his comments expresses doubt that it's possible for anyone to
> know all PSDs; the mention of a specific PSL in the abstract was an attempt
> to answer those doubts.
> 
> The second paragraph could be rewritten as
> 
> *The original design of DMARC applies only to domains that are registered
> with a domain name registrar (called “Organizational Domains” in RFC 7489)
> and nodes in the tree below Organizational Domains. Organizational Domains
> are themselves nodes in the tree below domain names reserved for
> registration, the latter of which will be referred to as Public Suffix
> Domains (PSDs) in this document.*
> 
> But how to address Dale's concerns about how one knows all PSDs?

To the extent this is a problem, it's RFC 7489's problem.  This document 
leverages it's existing definitions.  That's intentional.  While the current 
RFC 7489 definitions aren't ideal, as an extension to that work, I don't think 
it make sense to try and fix it here.  That's work for 7489bis.

Scott K