> On 23 Jul 2024, at 12:51, Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote: > >> The ANRW talk "Protocol Fixes for KeyTrap Vulnerabilities this >> afternoon by Elias Heftrig, Haya Schulmann, Niklas Vogel, Michael >> Waidner is proposing that there is a type roll for DS and DNSKEY. >> I dont think this is needed. The only change actually need is to >> add a new requirement that says that new DNSKEY algorithms MUST >> have DNSKEY RRsets that do not have colliding key tags. Validators >> can then depend on this behaviour with new key DNSKEY algorithms. >> The only question is do we add aliases for the existing key types. > > I can see 3 problems with this approach: > 1) we are only safe when the last algorithm that allows colliding keys > has been deprecated. That may be many decades from now. We are nowhere > near deprecating algorithms that use SHA-1.
And how is this different to migrating to IDKEY? The validator would need to support DS + IDDS + DNSKEY + IDKEY for a significant period. One can turn off support for algorithms without the new semantics. As for *SHA-1 many validators already treat those algorithms as unsupported. > 2) Some operators expressed concerns about prohibiting colliding keys, > especially in multi-signer setups. Delaying the deprecation of current > algorithms. There are several easy ways to address this. IDKEY would require this to be addressed. Nothing different here. > 3) My own analysis shows that for reasonable zones there is no need to > tolerate more than 1 signature verification failure per RRset. So > the gains are no all that high. One failure is one too many. IDKEY and this are about removing the need to have to process duplicate key ids when validating. We have done stuff like this before with the introduction of NSEC3. It is achievable. -- 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 To unsubscribe send an email to dnsop-le...@ietf.org
