I disagree that "keytag collisions have never been a problem other than in contrived examples" -- I cannot easily find the message now, but I posted an anecdote a while back about deleting the wrong key/keyfile because I stupidly just looked at the keytag, instead of the actual key.
Yes, the RFC makes it clear that the keytag should only be used as an optimization when looking for the right key, but humans (ie me) are dumb, and likely to take shortcuts. Is there any actual downside to saying something like "if the new key has a colliding keytag, just throw it away and try again"? And if you have multiple signers, partitioning the space both allows this, and provides a quick signal to a zone owner who is doing debugging at 3AM *which* signer generated the key... Without all of the MUSTs, and instructions to the validators, avoiding collisions, when easy, seems like a win to me. W On Thu, Jul 10, 2025 at 12:11 PM, John Levine <jo...@taugh.com> wrote: > It appears that Steve Crocker <st...@shinkuro.com> said: > >But as I write this, I realize the keytag is generated using the key. > >Different Signers are *highly* likely to have different keys, so there's > no > >need to create a salt. (It's been a *long* time since I looked at the > >algorithms.) > > The keytag is a 16 bit checksum of the key, made using roughly the same > checksum scheme used in TCP. Due to regularities in the keys there is only > about 14 bits of entropy in the checksum. > > It is easy to futz with the bits to create a bogus key with any desired > tag, but I don't know of any way to create real keys with tags in a desired > range that is better than trying repeatedly until you get one you like. > > Or, as I may have suggested once or twice, since keytag collisions have > never been a problem other than in contrived examples like keytrap, and > resolvers already defend against that, there is no remaining problem to > solve, and the senisble thing to do is nothing. > > R's, > John > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
