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

Mark Andrews <marka@isc.org> Tue, 14 October 2025 20:34 UTC

Return-Path: <marka@isc.org>
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 A4B4173825BF for <dnsop@mail2.ietf.org>; Tue, 14 Oct 2025 13:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_DNSWL_MED=-2.3, 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=isc.org header.b="d7mMpYUg"; dkim=pass (1024-bit key) header.d=isc.org header.b="onIuqXit"
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 r9NA5vLXEeiz for <dnsop@mail2.ietf.org>; Tue, 14 Oct 2025 13:34:53 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (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 D4EEB73825BA for <dnsop@ietf.org>; Tue, 14 Oct 2025 13:34:52 -0700 (PDT)
Received: from zimbra10.isc.org (zimbra10.isc.org [149.20.2.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id EACCD4D076D; Tue, 14 Oct 2025 20:34:51 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org EACCD4D076D
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.90
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1760474092; cv=none; b=U4kOPIFpjVTCNp642Qtwh3RHm7hovzNqoPaigMQv94sUHMZxk5vfRYniUMf7JS3GIXF6y9YgufaPXQAUbSAAhhOnoMgXK5d1w/R+jqEJ4Zes02S+0F0drMysX5xRjWs+TuwrH1P9h+6Jp70Pczd6VJs+6JAGZu23lzIf5dQ/hqg=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1760474092; c=relaxed/relaxed; bh=MIwWfO4zrKngKHSU/AzNk301rQYy+l4JKydEl35IgsU=; h=DKIM-Signature:DKIM-Signature:From:Mime-Version:Subject:Date: Message-Id:To; b=aPKzVAYYcN0Lp65mrbRBDl9Z9zFzRdW+wRB1Ob5UfJEPcVkZ8WgQk5D4z4Uk4DMwIB2XKhN22711XGtMLwJxpjyLKObbsUWH9hxImGb7SlzQIxyZjU5s5D4mj5NBrsz2nymraUDEfaKrwvkEmEUukO6my84tt6O5CBeGrsejLew=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org EACCD4D076D
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1760474091; bh=FyNg2hvqpXOKKfvfiPjzbamLBa8MWw1wnqC2lhVTNE8=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=d7mMpYUgKWW85M3uV83Z9kRR7m5fLClhXFletOT+c8rNmLGSAKdxjKbGlyetW9BpE pnegv0ROAaoycPw5oFiBpnZxFdb2wzDh7LadmTw1hi5Xt4i1BhDBWAP3v88Z/QDU5/ XBPvT5/yLuhQx7F1Ii0KJRYC4M3S5VZ21+LB8lZo=
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id E58112E602A5; Tue, 14 Oct 2025 20:34:51 +0000 (UTC)
Received: from zimbra10.isc.org (localhost [127.0.0.1]) by zimbra10.isc.org (Postfix) with ESMTPS id E17CB2E602A6; Tue, 14 Oct 2025 20:34:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra10.isc.org E17CB2E602A6
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1760474091; bh=MIwWfO4zrKngKHSU/AzNk301rQYy+l4JKydEl35IgsU=; h=From:Mime-Version:Date:Message-Id:To; b=onIuqXitaVyi4XE4yjJCBgyt9+eqvXNmOYJgLaDqc0rbM89bADtbNdJ2ppo2z+Lhw QyjLuV0S/ONIWMJc0uIAANhzvGVJtOQKQ5q7fPse1rZFUVSBTYE4XsHa50U48/E23U 8QDVyL1xZVbmuMdoW9RWcnRLFcdK6id5jvf2or68=
Received: from smtpclient.apple (n49-187-18-238.bla1.nsw.optusnet.com.au [49.187.18.238]) by zimbra10.isc.org (Postfix) with ESMTPSA id 952682E602A5; Tue, 14 Oct 2025 20:34:51 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Mark Andrews <marka@isc.org>
Mime-Version: 1.0 (1.0)
Date: Wed, 15 Oct 2025 07:34:38 +1100
Message-Id: <7F93DD75-7F1F-4EC1-BF07-1C303EA95F64@isc.org>
References: <20251014143601.5CDC8E175BE8@ary.local>
In-Reply-To: <20251014143601.5CDC8E175BE8@ary.local>
To: John Levine <johnl@taugh.com>
X-Mailer: iPhone Mail (22G100)
Message-ID-Hash: NOTFUMQQSCAISEYREPQYQSMXJSZWUKL4
X-Message-ID-Hash: NOTFUMQQSCAISEYREPQYQSMXJSZWUKL4
X-MailFrom: marka@isc.org
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/g34HbsFEyjymsacX8Crf048d0As>
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>

Go look at the number of queries a DNS server makes to resolve one query it gets.  CNAME chains 5+ deep. Nameservers needing to be looked up at other nameservers and maybe again.  Zones served from servers in other TLDs (that includes TLDs themselves).  A single lookup of a 5 label name has gone from 5 queries to close to 100.  With all of the anti practices we see today.
 
-- 
Mark Andrews

> On 15 Oct 2025, at 01:36, John Levine <johnl@taugh.com> wrote:
> 
> It appears that Mark Andrews  <marka@isc.org> said:
>> And when a single lookup results in nearly 100 fetches, results of which
>> all need to be validated, that “It’s just one collision” really adds up
>> fast if multiple validations strike it.  Lets say the zone for the nameservers
>> for a zone has a single collision.  Thats 8 validation attempts each with
>> a 50% verification rate on first attempt resulting in 8..16 crypto verifications
>> for 4 servers with A and AAAA records.
> 
> With no collisions, you'd have 8 validations.  With a collision you'd have 16.
> 
> Where does the 100 come from? Sounds like another reason we need an informational
> doc suggesting reasonable limits for validators.
> 
> R's,
> John
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> 
>>>> On 14 Oct 2025, at 06:03, Philip Homburg <pch-dnsop-7@u-1.phicoh.com> wrote:
>>> 
>>>> I think this is a false dilemma. There is more choice than just "no
>>>> document" or "a document prohibiting keytag conflicts".
>>> 
>>>> From the perspective of maintaining a validator I see it as binary:
>>> - going from accepting zero collisions to accepting one or more collisions
>>> introduces complexity. Going from one to more than one has hardly
>>> any impact on complexity. So this is clearly binary. I don't really
>>> care about discussion whether we should accept one or two collisions.
>>> - collisions are extremely rare. If you get two collisions then the chance is
>>> almost 100% that they were generated. So again it is binary. You accept
>>> zero collisions or you accept one collision. If you accept more than one
>>> collision it is just an invitation for attackers to DoS your validator.
>>> 
>>> 
>>> _______________________________________________
>>> DNSOP mailing list -- dnsop@ietf.org
>>> To unsubscribe send an email to dnsop-leave@ietf.org
>> 
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>> 
> 
>