[DNSOP] Re: New draft on collision free key tags in DNSSEC
"libor.peltan" <libor.peltan@nic.cz> Tue, 30 July 2024 07:41 UTC
Return-Path: <libor.peltan@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 8CEF9C151985 for <dnsop@ietfa.amsl.com>; Tue, 30 Jul 2024 00:41:39 -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, 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_BLOCKED=0.001, 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 nquS4XX56FMZ for <dnsop@ietfa.amsl.com>; Tue, 30 Jul 2024 00:41:35 -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 0D852C14F6F2 for <dnsop@ietf.org>; Tue, 30 Jul 2024 00:41:34 -0700 (PDT)
Received: from [IPV6:2a00:1028:8384:7a:41e3:48d6:fd0b:88c0] (dynamic-2a00-1028-8384-007a-41e3-48d6-fd0b-88c0.ipv6.o2.cz [IPv6:2a00:1028:8384:7a:41e3:48d6:fd0b:88c0]) by mail.nic.cz (Postfix) with ESMTPSA id BA06C1C11F3; Tue, 30 Jul 2024 09:41:31 +0200 (CEST)
Authentication-Results: mail.nic.cz; auth=pass smtp.auth=libor.peltan@nic.cz smtp.mailfrom=libor.peltan@nic.cz
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1722325291; bh=P2kwZziKazjgoOUGC2SwNyFamRFRL+k1vV0+L9o9Q+8=; h=Date:Subject:To:References:From:In-Reply-To:From:Reply-To:Subject: To:Cc; b=HrCgcnLLvj2IfgD6RWMhxV40T9ycRvzPtwnDTs1H3BuQqzlH7DqeNaSYzmRYRObJj dqRIbyNXr5p/55ciqZJV0scj2R6jLCwJNSSUSQKYOfGv9n0+iRR5Epm6+BG+3WSfCv u7Irzh8h2dqj0Pm8jWP24RPyEzQCdRrWhu7KmGbI=
Message-ID: <774ab370-5d66-4c0d-b0a4-6d9e9cec2549@nic.cz>
Date: Tue, 30 Jul 2024 09:41:31 +0200
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: en-US
From: "libor.peltan" <libor.peltan@nic.cz>
In-Reply-To: <CAHPuVdUveYraaGtrGveKTiLgP1L19G6g6=bsKsHjsPsP5fkiXg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.103.10 at mail
X-Virus-Status: Clean
X-Rspamd-Server: mail
X-Rspamd-Queue-Id: BA06C1C11F3
X-Spamd-Bar: -----
X-Spamd-Result: default: False [-5.09 / 20.00]; BAYES_HAM(-5.00)[100.00%]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com,ietf.org]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; NEURAL_HAM(-0.00)[-0.999]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:5610, ipnet:2a00:1028::/32, country:CZ]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]
X-Rspamd-Action: no action
Message-ID-Hash: EVLXQFNMEX33FCOGVSV6XCWQHRV4C3ON
X-Message-ID-Hash: EVLXQFNMEX33FCOGVSV6XCWQHRV4C3ON
X-MailFrom: libor.peltan@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/y8mkGkoYe3BKku13tnk4m2I2wKo>
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>
Hi all, as an authoritative DNS server (and signer) vendor, let me state my opinions on this topic and this draft. 1) I'd very much like to see more exact guidance of how the auth server / signer should prevent keytag collisions. For example, what our Knot DNS does is: (a) on a signle signer, when newly generated key causes collision, discard it and generate another; (b) in multi-signer (or offline-KSK) operation, fragment the keytag space between key generators (e.g. first signer discards any generated key with even keytags, the other one with odd ones). What I'm missing is a reasearch confirming (or rejecting) that this both is always possible -- i.e. that with existing (and future?) algorithms, it can't happen that the key tags would be always following a pattern (like being even all the time), putting the key generator in a hopeless loop. (We did not go ahead with key brokers or solving race conditions, as it seemed too much complexity for such a marginal problem as keytags.) 2) I would still vote for allowing one keytag collision per zone (not per whole chain-of-trust, like Bind does) instead of none. This would be more comfortable for many older/simpler signers and not too much additional work for validating resolvers, IMHO. 3) The idea of imposing the limit at first on new algorithms seems reasonable -- new algos mean new software which can easily adhere to new rules. However, we are in the situation that in fact, the existing resolvers already impose such (or very similar) limits on existing algorithms. So the document stating the requirement for auths/signer actually comes retrospectively, and I see no point in using this conservative enforcement strategy. Anyway, it can realistically take decades before any new algorithms seize some good portion of DNSSEC. In other words, that flag day has already silently passed. 4) It would look prettier if the document mentions also rules/preactices for validating resolvers. Stating what the validator should do (and what it must not do) when observing a tiny or a huge keytag collision. 5) I agree with Vladimir that keytag collision is just a small piece of the whole problematic of DNSSEC validator resource consumption. I'm not sure if it's wise to start with this single piece in one document, or working on a more covering document, exploring it all. But it's always useful if we somehow document the limits for signers and validators, so that they can interoperate smoothly. The goal is to prevent surprises when the signer signs somehow, and various validators do and don't validate due to imposing unexpected limits. This is what we should do! Thank you, Libor Dne 26. 07. 24 v 2:34 Shumon Huque napsal(a): > Folks, > > For discussion ... > > Mark Andrews, Elias Heftrig, and I have a new draft on collision free > key tags in DNSSEC. This topic has been in the air since the Keytrap > vulnerability disclosure -- and IETF120 hallway track conversations > this week prompted us to write up a rough initial proposal for this. > Will need much more fleshing out of details etc, but we hope this can > serve as a starting point ... > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-keytags-00 > > Shumon, Mark, Elias. > > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-leave@ietf.org
- [DNSOP] New draft on collision free key tags in D… Shumon Huque
- [DNSOP] Re: [Ext] New draft on collision free key… Paul Hoffman
- [DNSOP] Re: [Ext] New draft on collision free key… Yorgos Thessalonikefs
- [DNSOP] Re: [Ext] New draft on collision free key… Shumon Huque
- [DNSOP] Re: [Ext] New draft on collision free key… Yorgos Thessalonikefs
- [DNSOP] Re: [Ext] New draft on collision free key… Paul Wouters
- [DNSOP] Re: [Ext] New draft on collision free key… Paul Wouters
- [DNSOP] Re: [Ext] New draft on collision free key… Yorgos Thessalonikefs
- [DNSOP] Re: [Ext] New draft on collision free key… Shumon Huque
- [DNSOP] Re: [Ext] New draft on collision free key… John Levine
- [DNSOP] Re: [Ext] New draft on collision free key… John R Levine
- [DNSOP] Re: [Ext] New draft on collision free key… John Levine
- [DNSOP] Re: New draft on collision free key tags … Edward Lewis
- [DNSOP] Re: [Ext] New draft on collision free key… Edward Lewis
- [DNSOP] Re: [Ext] New draft on collision free key… Mark Andrews
- [DNSOP] Re: [Ext] New draft on collision free key… Mark Andrews
- [DNSOP] Re: [Ext] New draft on collision free key… John R. Levine
- [DNSOP] Re: [Ext] New draft on collision free key… Olafur Gudmundsson
- [DNSOP] Re: [Ext] New draft on collision free key… Paul Wouters
- [DNSOP] Re: New draft on collision free key tags … Vladimír Čunát
- [DNSOP] Re: New draft on collision free key tags … libor.peltan
- [DNSOP] Re: New draft on collision free key tags … Petr Špaček
- [DNSOP] Re: New draft on collision free key tags … Vladimír Čunát
- [DNSOP] Re: New draft on collision free key tags … Vladimír Čunát
- [DNSOP] Re: New draft on collision free key tags … Petr Špaček
- [DNSOP] Re: New draft on collision free key tags … Paul Wouters
- [DNSOP] Re: New draft on collision free key tags … libor.peltan
- [DNSOP] Re: New draft on collision free key tags … Peter Thomassen