[DNSOP] Re: 4 documents for consideration about the future of LocalRoot behavior.

Wes Hardaker <wjhns1@hardakers.net> Thu, 22 January 2026 21:52 UTC

Return-Path: <wjhns1@hardakers.net>
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 F001BABB0C6A for <dnsop@mail2.ietf.org>; Thu, 22 Jan 2026 13:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
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, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=hardakers.net
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 3IM7zX3bZDNv for <dnsop@mail2.ietf.org>; Thu, 22 Jan 2026 13:52:24 -0800 (PST)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (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 56CF9ABB0C5D for <dnsop@ietf.org>; Thu, 22 Jan 2026 13:52:17 -0800 (PST)
Received: from localhost (alt-vpn.ant.isi.edu [128.9.28.17]) by mail.hardakers.net (Postfix) with ESMTPA id 3F88620CFD; Thu, 22 Jan 2026 13:52:09 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net 3F88620CFD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1769118730; bh=S7I4FfX+yCy+5PssXxKTxgyg+LaSOzq8MWa2wMNXH+o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=d3P4VzFlbEcZggNQBY3u+Hv0EnzhMd6ioYyJQcmfn0CacweSDkg910v6hOOp6oBlo BFst7IfZUBEvCXsH6An7sPBcUuqeDyH/eWflAlFoycsogihO6lo3X1GvILnzg0vu45 cRrPF8GlYrWiDIcWjfGiX5cbCOk4Ksf/ccfvCm4Q=
From: Wes Hardaker <wjhns1@hardakers.net>
To: John Levine <johnl@taugh.com>
In-Reply-To: <20260122180259.48406F2B0D54@ary.qy> (John Levine's message of "22 Jan 2026 13:02:59 -0500")
References: <ybla4y6lwjf.fsf@wx.hardakers.net> <20260122180259.48406F2B0D54@ary.qy>
Date: Thu, 22 Jan 2026 13:52:08 -0800
Message-ID: <yblzf65iad3.fsf@wx.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Message-ID-Hash: ISAG27GUJGFEOKN6GJHKQ4PHINMHZC2B
X-Message-ID-Hash: ISAG27GUJGFEOKN6GJHKQ4PHINMHZC2B
X-MailFrom: wjhns1@hardakers.net
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, wjhns1@hardakers.net
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: 4 documents for consideration about the future of LocalRoot behavior.
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/597xjoR5EyPqsyIIegFehcv5qVY>
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>

"John Levine" <johnl@taugh.com> writes:

> I'd look at RFC 9718, about publising the DNSSEC root keys since I'd expect it
> to be published at roughly the same place. It might as well use a similar
> method. The key file is XML rather than JSON for historical reasons, and there
> is a detached signature which it appears nobody uses in favor of trusting the
> https certificate when you download it from data.iana.org.

I think it may be critical to have a signature which is separate from
the HTTPS cert because you want IANA to be the ultimate authority over
the contents with zero dependency on another agent.  Our current WebPKI
doesn't really protect against malicious parents (or even malicious
aunts and uncles except checking after the fact whether or not the cert
you used was invalidly issued by the wrong authority).

But, it certainly could be that the average implementation would never
check that more decentralized signature in favor of just trusting their
TLS stack.  But the ability to trust an IANA controlled key itself is
probably critical (IMHO) for absolute verification.

-- 
Wes Hardaker
Google