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

Paul Hoffman paul.hoffman at icann.org
Wed Feb 21 15:25:17 UTC 2018

On Feb 20, 2018, at 7:38 PM, Michael StJohns <msj at nthpermutation.com> wrote:
> On 2/14/2018 3:40 PM, Warren Kumari wrote:
>> Apologies if this isn't the right place to propose this - the
>> ksk-ceremony list didn't feel right...
>> I think that it would be a useful addition to the script to ensure
>> that, when a new KSK is generated, it does not have the same Key ID as
>> any previous KSKs. It is *does* have the same Key ID, it should be
>> discarded and a new one generated.
>> Rational: If we end up with multiple keys with the same Key ID it
>> becomes very tricky to run things like RFC8145, KSK Sentinel, etc.
>> Also, when doing troubleshooting / diagnostics, the key ID is an easy
>> thing to use to differentiate keys.
>> This has long been source of low level concern for me, and I've been
>> assured that if there were collisions during the ceremony, the right
>> thing would likely happen -- but I think that this is worth explicitly
>> noting what happens.
>> I *did* look at the scripts, and didn't see a note on this; 'pologies
>> if it is already covered and I missed it.
>> W
> Sorry - coming in late here.   AFAICT (absent some change buried in something after RFC4034) the key tag is supposed to be calculated from the RR RDATA  (appendix B of 4034) and is all of 16 bits long.

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.

> You may have an issue if you have two live keys with the same key tag - but the client code is supposed to do something smart (and 64k is not a big space to prevent collisions).
> You may also have an issue if an old revoked key and new live key have the same key tag (where when they were both live they didn't have the same key tag) - e.g. turning on the revoked bit in the flags field changes the key tag (called out specifically in 5011).
> Interestingly, you have a different issue (and much more likely issue) - where a KSK Key tag collides with one of the ZSK keys key tag - the more of these you generate, the more probable it becomes (birthday problem).
> In any event, the code has to deal with key tag collisions and do the right thing. Appendix B says so.

None of those three cases should never cause "an issue" if the software treats the key tag as an efficiency mechanism, not as an identifier.

> In any event, the code has to deal with key tag collisions and do the right thing. Appendix B says so.

Exactly right.

> 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.

--Paul Hoffman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3906 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180221/84e08bc5/smime.p7s>

More information about the ksk-rollover mailing list