So, I am the person who added key tags in the initial design of DNSSEC. The idea was just to, probabilistically, avoid unnecessary expensive validation attempts. If key tags are causing problems for some resolvers and validations are not such a problem with modern hardware, you can always just ignore the key tag and try validation with all keys. You still need to bound the effort you are willing to put in to evade some attacks.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Wed, Feb 14, 2024 at 11:06 AM Jim Reid <j...@rfc1035.com> wrote: > > > > > On 14 Feb 2024, at 15:17, Paul Hoffman <paul.hoff...@icann.org> wrote: > > > > On Feb 14, 2024, at 07:10, Jim Reid <j...@rfc1035.com> wrote: > >> That said, I think a minor tweak to the core DNSSEC specs would be a good > >> idea. For instance, whenever a validator comes across a key tag collision, > >> it MUST stop validating and either return a hard error or an unvalidated > >> response. > >> > >> My concern here is a bad actor using key tag collisions to disrupt > >> important validating resolver services. For some definition of important. > > > > That is not a "minor tweak", that will occasionally break validation in > > hard-to-detect ways. > > Could you please elaborate the hard-to-detect ways Paul? Key tag collision is > an obscure corner case (modulo the current keytrap excitement) and refusing > to validate in these circumstances seems more than reasonable to me. Fail > early, fail “safe”. The resolver would presumably log the error and return a > suitable response to the client. > > DNSSEC validation is already far too complex. Let’s not add more. IMO, the > pragmatic approach here would be for a validator to say “Duplicate key tags > mean the signer has messed up and I give up. Have a nice day.”. > > > The problem is not the collisions, it is the collisions causing almost > > unbounded processing. > > Indeed. So at the earliest opportunity for a validating resolver, nuke that > from orbit. It’s the only way to be sure. :-) > > > A better update would be to say "watch for excessive processing due to > > keytag collisions and abort when you detect it". > > Seems a bit fluffy to me. Define “excessive” and “watch". More code/moving > parts would be needed to implement this approach too. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
