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

[Michael StJohns]

On 2/21/2018 2:40 PM, Wessels, Duane wrote:
>> On Feb 21, 2018, at 2:28 PM, Geoff Huston <gih at apnic.net> wrote:
>>
>>> 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?)
>>>
>> I don't understand this question Mike - particularly “unrevoked brother” - could you describe in a little more detail what you are referring to here?
> Setting the revoke bit on a key changes its keytag.  Mike seems to be suggesting that maybe a query/signal for an unrevoked key should also match the revoked key.
>
> I'd say it should not in these cases.  Revoked keys should not be part of the trust anchor set and should not be matched.
>
> DW

Close to what I was thinking - but its more whether you can identify  a 
revoked key that *was* a trust anchor where you're trying to figure out 
the state of the trust anchors for a particular resolver.  5011 says to 
hang on to revoked keys for a bit  (remove hold down time) in the trust 
anchor store and depending on whether or not implementers followed that 
guidance you might be getting weird results.  (Note - I have not read 
either of the two documents deeply so this is more of a "have you 
considered" rather than a pointer to a bad situation.)


You may also want to consider the the situation of  Root DNSKEY RRset = 
{ Knew, Revoked(Kold)}   and where KeyTag(Knew) == KeyTag 
(Revoked(Kold)).    During the time that you're recording the revocation 
of KOld, there will be two RRSigs over the DNSKEY RRSet both with the 
same key tag - one by Kold and one by Knew

I don't know what that does for the various schemes, but is a condition 
that's possible.

Reviewing the key tag calculation - this is a basically the  sum of the 
key bytes expressed as big endian shorts with the carry bits added back 
in and masked to 16 bits.    I would have to run some simulations, but I 
would expect the values to have a bias of some amount - so not maybe a 1 
in 64K chance of collision.

*bleah* Mike