[ksk-rollover] Suggested update to the key ceremonies.

[Michael StJohns]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180221/4e3247d5/attachment-0001.html>