Re: [DNSOP] [Ext] About key tags and collision numbers

Mark Andrews <marka@isc.org> Thu, 29 February 2024 00:10 UTC

Return-Path: <marka@isc.org>
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 3CBCEC14F697 for <dnsop@ietfa.amsl.com>; Wed, 28 Feb 2024 16:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.407
X-Spam-Level:
X-Spam-Status: No, score=-4.407 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_ZEN_BLOCKED_OPENDNS=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="giKMNuhI"; dkim=pass (1024-bit key) header.d=isc.org header.b="mnTpAo39"
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 U3-RDD1SskJb for <dnsop@ietfa.amsl.com>; Wed, 28 Feb 2024 16:10:40 -0800 (PST)
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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A6BC14F71B for <dnsop@ietf.org>; Wed, 28 Feb 2024 16:04:33 -0800 (PST)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (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 B15B43AB1BA; Thu, 29 Feb 2024 00:04:33 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org B15B43AB1BA
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1709165073; cv=none; b=OXtV1wbHsXUB65wub4IxIB9vlwJ6raoW5KVMvZ7f1o5Htbtrry9QKCGX7s6DLId4tfsw8PouJKyeTcO2nnvCtSHT7JUxuavL9/fhpfVW11zMCaCkSqZZRTyydivlLqw/mkw9c3WnpDy9VbF0VlvQra1AKOwfQzodZn5lQjRleD4=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1709165073; c=relaxed/relaxed; bh=lWF40UDPAHqTlFwakHB7XzZ4C73i2XUgnSsybMAbejo=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=ZsbDWQP1k+32/JzmIDxof1Sbz9AmOWdoMcEfTbzQXHFZ/1leUR6dQ+XFks2BTJuEaorI5SlEZVYW0AXpSVrQdOAoGhb9mkfDm5Cid75v6pDVjjWig8UbqvWLrlMf0V7gqEnfgJg0YFKbyQ8nw5Hwa8cmG/VH+BWh1xRl6zfehG4=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org B15B43AB1BA
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1709165073; bh=fO5gQ/MULDA6vE3rakB3jK9LDM05euX/S5Ad5yjOddA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=giKMNuhILLfAQhz6jQTRB4XDXmnpnLagpHa1PwsWtgluMRNYZIVmEsa3Y6H+SIhYC wHvsB61t6dB+OwsXXYqGKUrqSkvImd9lm64V6ee1pjw9WYB6AdgBqXCOloU/HbVJBr y1lamf0cPZC9qAN7+y0fXHtINp3IcRDTaKeLdxI4=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id AA5BF1120D78; Thu, 29 Feb 2024 00:04:33 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 88CA91120E4B; Thu, 29 Feb 2024 00:04:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 88CA91120E4B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1709165073; bh=lWF40UDPAHqTlFwakHB7XzZ4C73i2XUgnSsybMAbejo=; h=Mime-Version:From:Date:Message-Id:To; b=mnTpAo39QJKh9LCxaKK8UTCdo3ogvFdb+OPOOheuSnb91H+1he+JeN30QQR2u9Icr v+/VVvwKIAxBwTNb6rmoSMYW9DiiurFzESQG7s/JPX2eK9raMdaBrGHYOWJhQZgTq0 Rn+3XQzxy8TnUokFEigNt9G0iMVONfM46YKUmdJo=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id 1LX0dCZxZSbp; Thu, 29 Feb 2024 00:04:33 +0000 (UTC)
Received: from smtpclient.apple (n49-187-27-239.bla1.nsw.optusnet.com.au [49.187.27.239]) by zimbrang.isc.org (Postfix) with ESMTPSA id C1BF71120D78; Thu, 29 Feb 2024 00:04:32 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <ac974641-5aae-381d-2a5a-e3676bdd8f4a@taugh.com>
Date: Thu, 29 Feb 2024 11:04:19 +1100
Cc: Shumon Huque <shuque@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6588E592-0E66-4445-BD1E-DAB36FF050D3@isc.org>
References: <9C4B65D7-EC9D-40BC-9B23-825F7FE8FB7E@isc.org> <20240227220905.E06018410007@ary.qy> <641C2E38-F1A8-435B-BA6F-770FEE9AEEA5@icann.org> <CAHPuVdWGQL5bRRqPj=-g_02y-7sZG-1WyiTCqktbdba=PuzEvg@mail.gmail.com> <ac974641-5aae-381d-2a5a-e3676bdd8f4a@taugh.com>
To: John R Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/e7T3N4AIrKDl4H-NRTXICwqnkyY>
Subject: Re: [DNSOP] [Ext] About key tags and collision numbers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Feb 2024 00:10:44 -0000


> On 29 Feb 2024, at 09:23, John R Levine <johnl@taugh.com> wrote:
> 
> On Wed, 28 Feb 2024, Shumon Huque wrote:
>> Banning keytag collisions outright today would not be a good idea - we risk
>> rendering some sights unresolvable through no fault of their own. DNSSEC
>> already has plenty of detractors, and we don't want to give them more
>> ammunition by creating problems in the ecosystem that can be easily
>> avoided. I think writing a BCP telling folks how to avoid collisions would
>> make sense though (and yes, it needs to cover the multi-signer case too).
> 
> The multisigner case is a database update problem which is surprisingly hard to get right.  Either you need locked updates which are slow and subject to hanging, or you need to detect collisions and retry, which has its own problems (BTDT).

DNSSEC doesn’t need instantaneous key generation.  Every step, including DNSKEY generation, has to support that stage being stalled today for DNSSEC to work.  Machines can be without power. Links between servers can be down.  If you don’t account at every stage for potentially stalling DNSSEC breaks.  Good key management requires checking multiple servers to where they are up to and stalling the process until everything is in the expected conditions.

Single signers today prevent duplicate key tags by regenerating keys on collision.  We can do the same thing with multi-signers.  There are a number of methods to do this.  There is the DNS UPDATE method (requires communicating with a broker).  There is dividing up the TAG space between providers (lots more keys thrown away which is why I rejected it when I initially thought of it, also requires enforcement at they publication stage).  Pick your poison.

> If we can live with small numbers of collisions, the whole problem is a lot more tractable.
> 
> Too bad there's no room for grease in DNSKEYs.  If you were allowed to add a byte or two of noise, you could constrain the range of the key IDs you generated, which would let you partition the ID space among multiple signers. That would be (other than the grease kludge) an elegant way out.
> 
> R's,
> John
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org