Prior to the news breaking that having two keys with the same key tag in a TLD led to an outage in late January, I was debugging some analysis code of mine that broke when a different TLD simultaneously published two DNSKEY resource records with the same key tag. This code had been fixed once before, when yet another TLD in 2019 had a KSK and a ZSK share a key tag. Yes, my code sucks, everyone already knew that a 16-bit value would inevitably suffer collisions when used to identity thousands-of-bits long pieces of data. Neither of two instances I'd dealt with were operationally impacting.
When DNSSEC was designed, the possibility of tags colliding was known. The validation process was defined to expect that a tag might lead to a non-singleton set of keys. When it came to key management, and the practice of storing keys in files named K<zone>-<sec_alg>-<key_tag>.public was derived, the lone developer of DNSSEC code (at the time) sidestepped the odds that key tags would collide by deleting the work done when creating a new key pair if the file to be used already existed. This side-stepping practice was never added to a standards document. (BTW, the reason for the "K" in the filename was that we developed the protocol using a test root zone, meaning the <zone> would be ".". A filename starting with "." is hidden in the OS systems we used then, so we needed a prefix.) Thinking back on why the key tag was created and used, it was to help distinguish what key was to be used to validate a signature in an RRSIG resource record. At the time we imagined a future where cryptography was used differently than it is today. We assumed that zones would have many keys, keys of different "strengths", lengths, and algorithms, all in current use. We didn't think about response size, that wasn’t in the forefront, because we knew we would blow past 512 bytes. Given a lot of keys, even being able to identify a subset from which to try all possible keys would be a win. Operators today will typically have two published keys - a KSK and a ZSK - with one used to sign just the DNSKEY resource record set and the other to sign all the other sets in the zone. Only when keys are being rolled would multiple keys of either type (cryptographic role) be seen. Operator practice has come to eliminate the need to subset the keys for manageability. Even if operators did deploy enough keys so that sub-setting the keys would be useful, the protocol lacks the ability to ask for keys with a certain key tag from a DNSKEY resource record set. When a query is issued for keys, it will always fetch the entire set. This might have been a design-time oversight. If the key tag had not been invented, the RRSIG resource record would still need to list the owner of the DNSKEY resource record that is needed to validate the signature, and this would be sufficient. Even ignoring the SEP bit in validation (as is required by rule), there would be few keys to try. Trying all the keys in sets today (usually 2) would be no worse than if there were 2 keys with the same key tag. Perhaps it is stretch - time needed to validate a signature is less of a concern now that it was on 1990's hardware (what we used in the lab). In the DS resource record, there's a hash of the key to provide some more protection which obviates the need for the key tag, come to think of it. (I could make the argument that the hash should have just been the key bits itself, but that's for another tirade.) I can't think of a good reason for the key tag anymore, seeing how 20 years of operations have evolved DNSSEC outside the lab eliminating the need to subset the DNSKEY resource record set. And now confusion over keys due to colliding key tags has contributed to one significant outage. Ok, one outage doesn't mean it's time to panic. The point of this tirade is not to eliminate the key tag from current use, but raises something to keep in mind when designing DELEG or future delegation mechanisms. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
