On 2/14/24, 08:54, "Petr Špaček" <pspa...@isc.org> wrote: > How many keytag collisions are you willing to allow & at the same time > protect validators from 2023-50387?
Admitting to reading the CVE link after replying: the issue doesn't need there to be a collision between keys. I could tie up validation by posting a data set with a lengthy (more than 1? 2? 3?) list of RRSIG resource records, each having the same key tag, different but still temporally valid inception, expiration time pairs, and falsely generated signatures. That could tie up a validator. The only reason I mention "same key tag" is that this meltdown happens only if there is indeed a key matching - only one is needed, but more could be there as well. The key tag isn’t the culprit here, it's that the process of validation is necessarily computationally complex, so falsely triggering a security response, which is a known tactic, is the root cause. Putting time (or resource) limits before denying is a reasonable response provided the issue is the result of a malicious situation. The goal is to design out benign causes of this. Keep in mind, my argument against the key tag is that in ordinary operations, the key signing the data will usually be the ZSK unless it is the DNSKEY resource record set, where it'll be the KSK. That's "ordinary", still one can twist configurations in all sorts of ways - that is what the designers did in the early development - and come up with gnarly situations where the key tag can be justified. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
