> On 29 Feb 2024, at 09:23, John R Levine <jo...@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: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
