[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