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

[Michael StJohns]

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

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

Later, Mike