[DNSOP] Re: New draft on collision free key tags in DNSSEC

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Mon, 29 July 2024 13:51 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65076C169423 for <dnsop@ietfa.amsl.com>; Mon, 29 Jul 2024 06:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPynr3YHr4IZ for <dnsop@ietfa.amsl.com>; Mon, 29 Jul 2024 06:51:51 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 ietfa.amsl.com (Postfix) with ESMTPS id D1BD8C169433 for <dnsop@ietf.org>; Mon, 29 Jul 2024 06:51:50 -0700 (PDT)
Received: from [IPV6:2a02:768:2d1c:226:3a85:e28d:75f9:2a46] (unknown [IPv6:2a02:768:2d1c:226:3a85:e28d:75f9:2a46]) by mail.nic.cz (Postfix) with ESMTPSA id 808B31C11ED; Sun, 28 Jul 2024 10:35:48 +0200 (CEST)
Authentication-Results: mail.nic.cz; auth=pass smtp.auth=vladimir.cunat@nic.cz smtp.mailfrom=vladimir.cunat+ietf@nic.cz
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1722155748; bh=qVk1Wvq+V/APUgVGPNXfR8R30+drB5NNOdUipBAYh0w=; h=Date:Subject:To:References:From:In-Reply-To:From:Reply-To:Subject: To:Cc; b=tUuFjVCzbW1NBiOfm/aPyXe5p+sufLWIDIBni6KU4/5M5ORF7yKt2OYNfEpenWTrg JfzEGE7wAZaRffGPlTmAmHHQ4jYTdsQdBEq7vx0DWewctLLXOgPnaQFUtnwbavE4f8 7xk7B0CNiN4+m6iY2wxv0Bewj8WsFPTc3BdNeoM8=
Content-Type: multipart/alternative; boundary="------------aFvI2RNe2aLaRHgQK0H7uiux"
Message-ID: <1860c68a-b730-4924-8759-4127072bab75@nic.cz>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Shumon Huque <shuque@gmail.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>
References: <CAHPuVdUveYraaGtrGveKTiLgP1L19G6g6=bsKsHjsPsP5fkiXg@mail.gmail.com>
Content-Language: cs, en-US
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
In-Reply-To: <CAHPuVdUveYraaGtrGveKTiLgP1L19G6g6=bsKsHjsPsP5fkiXg@mail.gmail.com>
X-Virus-Scanned: clamav-milter 0.103.10 at mail
X-Virus-Status: Clean
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.02 / 20.00]; BAYES_HAM(-5.00)[100.00%]; R_MIXED_CHARSET(1.07)[subject]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,ietf.org]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; NEURAL_HAM(-0.00)[-0.999]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:44489, ipnet:2a02:768::/32, country:CZ]; FROM_EQ_ENVFROM(0.00)[]; TAGGED_FROM(0.00)[ietf]; MIME_TRACE(0.00)[0:+,1:+,2:~]
X-Rspamd-Action: no action
X-Rspamd-Server: mail
X-Rspamd-Queue-Id: 808B31C11ED
Message-ID-Hash: XEOUNXDOTTDCPL6M6XX6CAUZYARGOAFV
X-Message-ID-Hash: XEOUNXDOTTDCPL6M6XX6CAUZYARGOAFV
X-MailFrom: vladimir.cunat+ietf@nic.cz
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: New draft on collision free key tags in DNSSEC
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nHxZa-qK5mc1xHm2gguFpiE1q9U>
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>
Date: Mon, 29 Jul 2024 13:51:55 -0000
X-Original-Date: Sun, 28 Jul 2024 10:35:47 +0200

I believe that such a draft is NOT worth all the implied human effort, 
I'm afraid.  The idea isn't new, but let me reiterate my points below.

Even if we forbid all keytag collisions, there will be many more ways 
how attackers may attempt to generate lots of work for validating 
resolvers.  (many RRSIGs, combination with CNAME chains, etc.)  I don't 
think such piecemeal approaches will really help, especially if they'd 
take many years to actually restrict the attacks.

I'm aware that this is close to a "slippery slope" fallacy, but all 
things considered, completely eliminating keytag collisions doesn't seem 
worth the effort to me.  On the other hand, note that bigger collisions 
are extremely unlikely (e.g. four keys, all with the same tag).  You 
want to minimize the DNSKEY set sizes anyway, due to space restrictions, 
so you can't really have dozens at once legitimately.

Strictly enforcing collision avoidance might complicate some less 
centralized use cases.  So such an RFC certainly isn't close to free or 
without risks.

--Vladimir | knot-resolver.cz