Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt

Alessandro Vesely <vesely@tana.it> Mon, 22 March 2021 11:13 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 02FE53A1168 for <dmarc@ietfa.amsl.com>; Mon, 22 Mar 2021 04:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 nd8I75f-uwXU for <dmarc@ietfa.amsl.com>; Mon, 22 Mar 2021 04:12:59 -0700 (PDT)
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 DF5DD3A1163 for <dmarc@ietf.org>; Mon, 22 Mar 2021 04:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1616411572; bh=yEpp16qXTXTaWZmwRGFcpi7WOX8Hkkk2dsWRTNcPrCg=; l=3650; h=To:References:From:Date:In-Reply-To; b=AI/QbB2Tl87ENtw/fyZLjbsmKYL3U+1z6VWiCpuypmL5uNXMgS4vBYzxfIbAMlVn7 qb0O9fkBWPcHp3CyvsMvklQfmInDqIxd/1GTqMWTDRQZIgB8roNkyDFGVWQiB2DzHk U04LbG1KY6P9QLCK8Sp4Kyk6A3u68kAYdA0UX8FrXKnMvx6K3K4R+A11fvs/0
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 00000000005DC0B0.0000000060587BB4.00004CCB; Mon, 22 Mar 2021 12:12:52 +0100
To: Tim Wicinski <tjw.ietf@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
References: <161616297099.26288.5532647192522385084@ietfa.amsl.com> <b6acffdb-9700-b078-6cd2-e76d7f677f32@tana.it> <CADyWQ+Gvu3Nw0kMLkJ=kAVZkG+yf-Zo+nJ+PwL0pekXcG7TDbw@mail.gmail.com> <27e3365b-0e7f-f6c1-b702-ab9ab4ba8379@tana.it> <CADyWQ+FPuCSEiLtD9sOWAcjngRteyfYCDHt_6ftCpcxtYagUKA@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <f42611db-d73a-159e-539a-5f8e9f0114a8@tana.it>
Date: Mon, 22 Mar 2021 12:12:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <CADyWQ+FPuCSEiLtD9sOWAcjngRteyfYCDHt_6ftCpcxtYagUKA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/poMzovDEmG7Crxl2rRWvXzdxxhw>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt
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: Mon, 22 Mar 2021 11:13:04 -0000

On Sun 21/Mar/2021 23:03:47 +0100 Tim Wicinski wrote:
> 
> I have some suggested text I'd like to hear some feedback on.
> 
> ---
> 
> 
> In the Introduction, the suggested change is
> 
> OLD
> 
>     To determine the organizational domain for a message under
>     evaluation, and thus where to look for a policy statement, DMARC
>     makes use of a Public Suffix List.  The process for doing this can be
>     found in Section 3.2 of the DMARC specification.
> 
> NEW
>     To determine the organizational domain for a message under
>     evaluation, and thus where to look for a policy statement, DMARC
>     makes use of a public suffix list.  The process for doing this can be
>     found in Section 3.2 of the DMARC specification.  Currently the
>     public suffix list being used is the most common one that is
>     maintained by the Mozilla Foundation and made public at
>     http://publicsuffix.org [1].


I like this approach.  However, it may conflict with a minor issue reported by 
Dale last year, which I quote:

  - It would be very helpful if the Introduction could state, in a few
    sentences, the purpose and operation of DMARC, thus informing the
    reader of the framework whose deficiencies this document attempts to
    address.  In particular, one shouldn't have to read the DMARC RFCs
    to be able to read this document and understand its general import.
https://mailarchive.ietf.org/arch/msg/dmarc/0SG2-c3BnOakafKWnseuMKXBVIE

To help casual readers, PSL should be introduced after PSD is clarified.  This 
paragraph about the PSL could be moved downward (for example to Section 3), and 
replaced by a new one introducing PSD instead.  Such a paragraph could perhaps 
be worded around something like this:

     A public suffix domain (PSD) is a domain under which multiple parties
     that are unaffiliated with the owner of the PSD may register subdomains.  A
     domain registered that way is an organizational domain, and its subdomains
     can be assumed to be administratively affiliated with it (although in some
     cases they represent independent entities.)


> [...]
> 
> In section 1.2 "Discussion", this will change.
> 
> OLD
>     o  Branded PSDs (e.g., ".google"): These domains are effectively
>        Organizational Domains as discussed in [RFC7489].  They control
>        all subdomains of the tree.  These are effectively private
>        domains, but listed in the Public Suffix List.  They are treated
>        as Public for DMARC purposes.
> 
> NEW
> 
>     o  Branded PSDs (e.g., ".google"): These domains are effectively
>        Organizational Domains as discussed in [RFC7489].  They control
>        all subdomains of the tree.  These are effectively private
>        domains, but listed in the current public suffix list.  They are
>        treated as Public for DMARC purposes.


I'd weaken a bit the statement about the policies of Charleston Road Registry 
Inc.  Then, semantically, .google is not treated as a PSD because it's listed 
in the PSL, which could possibly happen because of a maintainer's passing 
fancy, but because it is actually operated by a public registry, as required by 
an ICANN contract[*].

     o  Branded PSDs (e.g., ".google"): These domains sound very much
        like Organizational Domains as discussed in [RFC7489], since they
        control all their subdomains.  However, formally they are public suffix
        domains, operated by a public registry.  Therefore, they are currently
        treated as PSDs for DMARC purposes.


Best
Ale
-- 

[*] https://archive.icann.org/en/tlds/application-process-03aug00.htm#1d