[DNSOP] The past ... Re: [Ext] About key tags

[Edward Lewis <[e-mail]>]

On 3/1/24, 10:52, "DNSOP on behalf of Joe Abley" <[e-mail] on behalf of [e-mail]> wrote:
>It's a shame that the design of keytags didn't anticipate a need for algorithm agility. 

I imagine that this was said with one of Joe's famous chuckles...but...yeah, there's a lot of places we didn't anticipate wisely...

There's a lot we could have done differently, but at the time it wasn't apparent.  When I raised this topic, my goal was to note that we should try to recreate key tags in any potential future design, such as might be enabled by DELEG.  I didn't intend to say that we ought to erase key tags from use today.  We have a choice to "just live with it" or "try to fix it" and we usually choose the former for the sake of expediency.  Continuing to do that will eventually get us to a collapse, I fear.  Maybe not when any of us are still working (to use a tired old phrase), but at some time.

I've been toying with some other, not yet documented, idea related to DNSSEC, where I concluded that including the entire key was better than either a key tag or even a hash, due to the long-term nature of the records.  E.g., if I have a key and I publish only its SHA-256 hash now and then later only a SHA-384 hash, how would you know it’s the same key if the key hasn't been published anywhere?  In that case, I need to make the key known in its entirety.

After the key tag thread began to rage, I had another thought, which would be to store DNSKEY resource records with owner names being <key_tag>.<zone_name>, which would make it easier to see the collisions. Like:

12345.example.com. DNSKEY ....something....
23456.example.com. DNSKEY ....something....

It would also enable querying for just the key(s-if collision) needed.  But this wouldn't make it easy to see if some key in the set had some special DELEG bit and it would cause problems for Automated Updates (which discovers new trust anchors via a time begun upon first sight).  And of course, storing keys this way would be a major protocol overhaul.  It's just a thought - and discounts some of the meanings we've overlayed on the DNSKEY resource record set as time has progressed.