On 2/21/2018 10:25 AM, Paul Hoffman wrote:

Warren's point (which many other people gave a +1 to, and IANA said they intend to implement) is not to prevent two identical keytags in the root zone DNSKEY RRset (Mike) or anywhere in the root zone (Ed), it is to prevent confusion in other places where the key tag is used, such as trust anchor stores. The key tag is used in many places where an operator would enter, or at least check, the trust anchors.

Um any code stupid enough to use the key tag as a solid handle for the key should be ripped out and stomped on. AFAICT, the key tag calculation is no better than a CRC in cryptographic strength - and only 16 bits at that. What should be happening is that entering the presentation form of the DS as a trust anchor should grab the referred to DNSKEY, do a calculation and compare the calculated trust anchor key tag to the entered one. I'd surprised if enough implementations do that.

So if you're really going down this path, you've probably got a lot more work than just checking against older KSKs.

I fully disagree with this, and with Ed's assertions. Checking for a matching key tag in the current and previous KSK set is sufficient to reduce ambiguity for manual use of key tags, which is what Warren's suggestion was about.

So what you're saying is that you're going to conditionally repeat an operation that has a ritual associated with it (and indeed modify the ritual so this happens) until you get non-matching key tags for the sole purpose of someone later on looking at the key and saying "not a match". A complex ritual with specific requirements and a large cost in human time... OK.

Key tags exist on DS records and RRSig records. In the DS records, the hash of the key is a better handle to differentiate possibly matching keys. In the RRSig records - you're kind of stuck in that you possibly don't know who of multiple possibilities signed the record until after you've checked all of the tag matching signing keys.

To his basic point of RFC8145 and KSK sentinel - if you're using the Key Tag as a handle then all of the "you must accept ambiguity" stuff from Appendix B of RFC4034 applies. Perhaps using something other than the key tag (e.g. hash of the public key - the first and last 4 bytes of the public value of the key... ) might have been smarter. Say something with at least 32 and preferably 64 bits of uniqueness rather than the 16 bits of the key tag.

So my base point is - don't try to fix the wrong problem. Key tags are what they are and will remain as such. With 16 bits, collisions are inevitable at some point and may actually occur *after* the keys are generated (- revoked keys). Fix 8145 and KSK sentinel instead.

(And by the way - does any of the 8145 or KSK sentinel implementations correctly match a revoked key with its unrevoked brother?)

Later, Mike