Yeah, regardless of whether the protocol allows it, I would not want colliding keytags in any zones that I operate. Just so that answers can be accepted without any unnecessary signature verification operations.
I've made a note to describe a procedure to avoid colliding keytags in rfc8901-bis (if/when we get around to writing that). Shumon. On Fri, Feb 16, 2024 at 3:05 PM Mark Andrews <ma...@isc.org> wrote: > The problem with key tag collisions is that you turn verify operations > from 1 per RRset to 1.5 per RRset for a two RRSIGS with the same tag and > algorithm. You can figure out the average number of verify operations with > 3, 4 etc. Those extra verify operations are completely avoidable by > rejecting a new key which would cause a key tag collision. Generating a new > key is not hard to do. Adding a check against the common key store is not > hard to do in a multi-signer scenario. It can be completely automated. > Request the set of in use tags. Generate a new key that doesn’t collide. > Try to reserve the new key tag. Repeat if necessary. > > We could even use the DNS and UPDATE to do that. Records with tuples of > algorithm, tag and operator. Grab the current RRset. Add it as a > prerequisite with a update for the new tag. > > -- > Mark Andrews >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
