> 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
