The reason this topic is on the list now isn't validation, it began as a key
management issue. Donald's right (of course) in what he now posted. But the
performance gain of sub-selecting keys based on key tag is less than originally
anticipated and comes at the cost of confusion in key management.
Specifically, when someone or some code drops the wrong key (of a set matching
the key tag) from the published DNSKEY resource record set.
On 2/14/24, 11:16, "DNSOP on behalf of Donald Eastlake"
<dnsop-boun...@ietf.org on behalf of d3e...@gmail.com> wrote:
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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!4Yew08yX--_q21CDURxWgJ3FMduBzAMqxHM8nzhuNqxSG67QOt4TUQW28rmrzRRuKSZumgJqIXPyX5Q0wLjx98A$
[ietf[.]org]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!4Yew08yX--_q21CDURxWgJ3FMduBzAMqxHM8nzhuNqxSG67QOt4TUQW28rmrzRRuKSZumgJqIXPyX5Q0wLjx98A$
[ietf[.]org]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
