[dmarc-ietf] Public suffix and 3rd level, was Summary comments on draft-ietf-dmarc-psd

Alessandro Vesely <vesely@tana.it> Sun, 15 March 2020 18:56 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 5792E3A1A93 for <dmarc@ietfa.amsl.com>; Sun, 15 Mar 2020 11:56:52 -0700 (PDT)
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, 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 Z9KaW2cXYDyP for <dmarc@ietfa.amsl.com>; Sun, 15 Mar 2020 11:56:50 -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 2B0403A1A92 for <dmarc@ietf.org>; Sun, 15 Mar 2020 11:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1584298604; bh=2RNTjPqXge+N5nA9esT1JX4SBDZdWzHFeYRCRBEdVZo=; l=3812; h=To:References:From:Date:In-Reply-To; b=BYQzLg2WVyZOhhbMpOCrZC8LPceP6mvtUtQFfWvUI3/Oe4DJnZYw93OvzUOjx5edI MzMBC+ohKwW08ES4rjefcnrWTDRPiV1FTUd3gW0SOWJloQhOfuL//gaVfPlNqe5Zsl /VLFSu3NejCra713C9976CNvXgIC9TqeKID7aa9hNNbOjsk+ZLhysj3L8DfBw
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [192.168.1.131] ([93.37.83.242]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC00B.000000005E6E7A6C.000044B3; Sun, 15 Mar 2020 19:56:44 +0100
To: dmarc@ietf.org
References: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net> <856481e5-7497-ba81-fb1f-dba2b645276c@tana.it> <378e83ae-f326-695c-a3c2-d0e099fd97b4@dcrocker.net>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <075b4f3a-53ae-31b2-904d-0fb6752bf3fd@tana.it>
Date: Sun, 15 Mar 2020 19:56:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <378e83ae-f326-695c-a3c2-d0e099fd97b4@dcrocker.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/LXRT4GZe9Ivaat823ntHzubHG7w>
Subject: [dmarc-ietf] Public suffix and 3rd level, was Summary comments on draft-ietf-dmarc-psd
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, 15 Mar 2020 18:56:52 -0000

Hi,
I changed the subject as I only reply to that part of the original post.

On Sun 15/Mar/2020 13:49:26 +0100 Dave Crocker wrote:
> On 3/11/2020 10:08 AM, Alessandro Vesely wrote:
>>> 1. These are not 'public' suffixes (1) The concept of a 'public'
>>> suffix refers to domain names associated with registries subject to
>>> externally-imposed operational policies.  For want of a better
>>> term, these operations are regulated.  The domain suffixes that PSD
>>> attends to are not public registries. 
>> ... For "public suffix", I propose we stick to the definition
>> referred by rfc8499.
> 
> OK, let's do that:
> 
>      "Public suffix: "A domain that is controlled by a public registry."
> 
> 
> I gave three examples of types of domains, like the owner of
> example.com getting .example.  In each of those 3 cases, these domain
> names are not controlled by a public registry.  So they are not
> "public suffix domains".


I agree that that definition is not all that well reasoned.  Are there
private registries?  Rfc8499 also talks about "public DNS", where the
adjective bears a slightly different meaning.

We need to define Operational Domain.  Debating about the semantic
meaning of "public" doesn't seem to help much.


>>> 3. DMARC wants the Organizational Domain The existing DMARC model
>>> is a) look under the full domain, and then b) look under the
>>> Organizational Domain, as a fallback.  My strong suggestion is to
>>> keep the model as simple as that. The argument for adding just this
>>> one more layer of Organizational Domain seems modest, primarily
>>> because it is purpose-built to handle a new, special case, rather
>>> than because it represents a considered, general case. 
>> Having three levels instead of two sounds quite general. 
> 
> That's nice.  And there is a common computer science view that it can
> be.  But in this case it isn't true.  Rather, it is a very
> specialized, purpose-built addendum.  There is nothing general about
> it at all.


It would certainly be more general if there was a way to specify it
independently of the public suffix list.  Let me quote another
paragraph of yours, which describes the problem well:


> [...]

> The organization that controls this bit of hierarchy controls the
> domain name the PSD draft is seeking to identify and use.  It also
> controls the one below it that is otherwise viewed as the
> organizational domain.  For some organizations, there will be other
> administrative boundaries, below this, for subordinate companies or
> departments, or the like. For large, complex organizations, there can
> be an extensive administrative hierarchy and it might be reflected in
> a large, complex domain name hierarchy.


The non-general way to define a 3rd level is to have the top suffix be
"public" (in the sense of the PSL) and then have the organization
participate in PSD DMARC.  According to the experiment, that allows
subordinate companies or departments to publish their own policy, and
still have an top-level policy as a default and for non-existent domains.

I agree that having to call "pubic" an organization just because it is
so wide as to require three levels doesn't seem to be semantically
consistent.  The mechanism works, though, and covers known use cases.

The general way would allows example.com to behave like .example
without disturbing the registries and the PSL.  However, to work out
what mechanisms are needed is daunting.  Any suggestion on how to
shape that?  To me, it seems it would likely require more radical
changes to DMARC than the low hanging fruit at hand.  In addition, we
would then have the problem of how to define "private" the relevant
TLDs, despite their ICANN agreement.


Best
Ale
--