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

Philip Homburg <pch-dnsop-6@u-1.phicoh.com> Wed, 23 April 2025 14:15 UTC

Return-Path: <pch-b6CAFA0C7@u-1.phicoh.com>
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 F13FF20027B7 for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 07:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 yTo6aOjwFwcW for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 07:15:30 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [45.83.6.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3E1E120027B2 for <dnsop@ietf.org>; Wed, 23 Apr 2025 07:15:29 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305) (Smail #158) id m1u7asT-0000MtC; Wed, 23 Apr 2025 16:15:05 +0200
Message-Id: <m1u7asT-0000MtC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-6@u-1.phicoh.com>
Sender: pch-b6CAFA0C7@u-1.phicoh.com
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>
In-reply-to: Your message of "Wed, 23 Apr 2025 13:50:42 +0000 ." <BE721880-6254-48F4-9F91-567A99E0511B@icann.org>
Date: Wed, 23 Apr 2025 16:15:04 +0200
Message-ID-Hash: N6BHD2SFJPLXRPDFJWBBDC3SVZWRLUWL
X-Message-ID-Hash: N6BHD2SFJPLXRPDFJWBBDC3SVZWRLUWL
X-MailFrom: pch-b6CAFA0C7@u-1.phicoh.com
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: 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/yjBhT2tnFY9JSuACCiEJcr9JNUY>
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>

> The ICANN Board acted
> based on recommendations from the ICANN SSAC in SSAC113:
> https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-
> ssac-reports/sac-113-en.pdf
> 
> There are plenty of SSAC members on this mailing list; they can
> explain why the report (and thus the recommendations to the board)
> do not include a recommendation for insecure delegation.

Obviously, what happens in ICANN, happens in ICANN with ICANN procedures, etc.
No need to have a discussion about that.

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.

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.