[DNSOP] Re: Collision Free Key Tags for DNSSEC draft

Jim Reid <jim@rfc1035.com> Wed, 09 July 2025 18:09 UTC

Return-Path: <jim@rfc1035.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 3AA2B4206A50 for <dnsop@mail2.ietf.org>; Wed, 9 Jul 2025 11:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.232, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 h7zK_y2ZKUio for <dnsop@mail2.ietf.org>; Wed, 9 Jul 2025 11:09:42 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (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 CE4B04206A43 for <dnsop@ietf.org>; Wed, 9 Jul 2025 11:09:38 -0700 (PDT)
Received: from smtpclient.apple (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id A523A2420E4A; Wed, 09 Jul 2025 18:09:37 +0000 (UTC)
From: Jim Reid <jim@rfc1035.com>
Message-Id: <D9F87870-CAFE-4411-8C5D-CFCFB0C9AE4D@rfc1035.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_302FD917-B6E1-498C-AC99-402E6CB96670"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Date: Wed, 09 Jul 2025 19:09:36 +0100
In-Reply-To: <20b9ba28-cf32-4ca7-86d8-0de44662ab2b@isc.org>
To: Petr Špaček <pspacek@isc.org>
References: <0c4715d1-cd1b-4726-a372-6ac3c26af786@nic.cz> <45260BA6-B4C0-4A2C-8E69-51D72C833C1F@nohats.ca> <b5674176-304a-e96e-22d4-d2a3818a1195@taugh.com> <a6aed8f2-51c7-4662-be8c-a5ff6ac8f5a1@nlnetlabs.nl> <20250708154239.DCDCCD25776F@ary.qy> <80901863-ec1a-4723-9169-78e28f504dd6@isc.org> <20250709021141.0FED8D268E7A@ary.qy> <eec6337c-9a10-497d-9dc2-ea6d1d66257a@isc.org> <e9d96900-1136-1fc1-9d72-1715421cfa8f@taugh.com> <1422A65D-7BA0-4638-9332-32B792B15E4B@rfc1035.com> <20b9ba28-cf32-4ca7-86d8-0de44662ab2b@isc.org>
X-Mailer: Apple Mail (2.3826.600.51.1.1)
Message-ID-Hash: FOTEZ3AUGE7EKDFSBMDPNSWTHJ34SSTM
X-Message-ID-Hash: FOTEZ3AUGE7EKDFSBMDPNSWTHJ34SSTM
X-MailFrom: jim@rfc1035.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: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: Collision Free Key Tags for DNSSEC draft
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/trTVxRZ3P91Ec010JILhGh9aV2I>
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 9 Jul 2025, at 18:24, Petr Špaček <pspacek@isc.org> wrote:
> 
> Can you clarify source of your confidence about this 'not causing issues'?

Mental arithmetic. There are 2^16 possible key tags => there's a one in 2^15 chance a new tag clashes with an existing one. If a DNSSEC key changes every day, it'll take 2^15 days (~100 years) on average before there's a collision. That's good enough for my definition of "not causing issues". YMMV.

I accept there's a theoretical possibility of a key tag clash causing issues Petr. IMO that possibility is just too low to bother about. If this has caused actual operational problems, surely this WG would have heard about them by now. AFAICT it hasn't.

You said partially bogus RRSIG RRsets can cause a validator to exceed its limit of allowed validation attempts. Fine. So please suggest how to fix that problem. It's not clear to me how key tag collisions has any bearing on how to deal with bogus RRSIGs.