[DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld

Joe Abley <jabley@strandkip.nl> Wed, 23 April 2025 16:19 UTC

Return-Path: <jabley@strandkip.nl>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 55802201AF4E for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 09:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
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, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzHdjNy1IHJk for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 09:19:10 -0700 (PDT)
Received: from outbound.st.icloud.com (p-east2-cluster2-host2-snip4-7.eps.apple.com [57.103.78.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 157D5201A80F for <dnsop@ietf.org>; Wed, 23 Apr 2025 09:16:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=sig1; bh=Cl4IXx9Iw0+2yZC2ox9lZ4FqxdCM+RK8UM0yhC0xyB8=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To:x-icloud-hme; b=Dak4xL2lzzFgfJEkrLi0XGtglfnzcq96USGUv1aPHQTAA3TGgg1Atk0+rFCvtQvW3 iCAq+gsx9kQMZ8O2y15Aqv+UnLb8XDZZWpSl1CauEL2sWwdMSacchjmHx4N9hrylSL a9nD6wO6KwyyEPEjQRJCCgAsACCAr4nMhwZdUUq/rl6a/kAdSZFcw1Fip1822bkoGR ibtN/433LVWH9A2BuW3WleaJoZfBG4b/aL2pubv/9gUDieMH7S2YmdH4+9+dybcbpT KKurLI5WfUKc/lTO+OkqFeFsYAUiQdn6HUNK8OkE/hTBWE1tMJPa+QV4DhnXSf9boN J5cjqDknjIxFA==
Received: from smtpclient.apple (st-asmtp-me-k8s.p00.prod.me.com [17.42.251.67]) by outbound.st.icloud.com (Postfix) with ESMTPSA id 64AB81800A28; Wed, 23 Apr 2025 16:16:52 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
From: Joe Abley <jabley@strandkip.nl>
In-Reply-To: <m1u7asT-0000MtC@stereo.hq.phicoh.net>
Date: Wed, 23 Apr 2025 18:16:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <01E23110-9A50-4187-8A54-34D514504F9B@strandkip.nl>
References: <m1u5h1G-0000LcC@stereo.hq.phicoh.net> <83666fd3-a51f-46e1-a5ac-0b9a46361480@desec.io> <49E3B1B6-E960-4A46-9C5D-2721FD57132D@depht.com> <3b5fb9e7-8a2b-420f-a2fb-dd6f6a0b88ae@isc.org> <89047B78-A2B1-43F2-A996-94DF1E90538A@depht.com> <cc84f69c-c349-4d91-b942-80221b564a9b@isc.org> <ac48e27d-479f-42f3-b87f-891220ef2fe8@app.fastmail.com> <BE721880-6254-48F4-9F91-567A99E0511B@icann.org> <m1u7asT-0000MtC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-dnsop-6@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3826.500.181.1.5)
X-Proofpoint-GUID: 4EdT-Ml2stbzvDtXu23usFnJoOlJsD-t
X-Proofpoint-ORIG-GUID: 4EdT-Ml2stbzvDtXu23usFnJoOlJsD-t
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1099,Hydra:6.0.680,FMLib:17.12.80.40 definitions=2025-04-23_09,2025-04-22_01,2025-02-21_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 spamscore=0 bulkscore=0 mlxscore=0 phishscore=0 adultscore=0 suspectscore=0 malwarescore=0 clxscore=1030 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2504230114
Message-ID-Hash: 2ASHOETFMNA4OKIT5HSGTPZSNWXNYUU5
X-Message-ID-Hash: 2ASHOETFMNA4OKIT5HSGTPZSNWXNYUU5
X-MailFrom: jabley@strandkip.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org, Paul Hoffman <paul.hoffman@icann.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7Jsx7LOE8oq7_0EUeAFnlj5BBlA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

On 23 Apr 2025, at 16:15, Philip Homburg <pch-dnsop-6@u-1.phicoh.com> wrote:

> But I want to say I'm surprised that a document by 'the ICANN Security and
> Stability Advisory Committe' does not mention DNSSEC at all, except in a
> footnote in an appendix. And does not analyse an insecure delegation from
> the root.
> 
> For this working group, I think it is safe to assume that ICANN will not
> create an insecure delegation for internal.

I don't know how to predict what ICANN will or will not do. I'm also not sure why it is useful to speculate.

I was a member of SSAC at the time SSAC made its recommendation to the ICANN board, but I was not one of the people who contributed significantly to the document as far as I remember, so be aware (as usual!) that everything I say may be nonsense.

I think the SSAC document does not discuss or propose an insecure delegation from the root zone in order to avoid the advice to the board being complicated by conflicts with existing root zone management (both in the general sense and in the sense of RZM, the software used to manage delegations from the root zone).

I am fairly confident the mechanics of the implementation were understood and discussed by those involved in writing the document. I don't think it's reasonable to imagine that people just didn't think of this. Given the number of times we have heard Mark Andrews talk about this at microphones around the world it seems impossible that anybody is unaware of it.

Personally, I agree with John Levine that it's common practice for people to use top-level domains in a private environment and whatever complexities might exist in theory with DNSSEC do not seem to be much of a problem in practice. So I agree that this particular issue does not seem like much of a reason for this working group to spend time on this.

> So in my opinion this draft should not be adopted. The best solution is
> no IETF document at all. That leaves the IETF out of this issue.


Joe