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

[Edward Lewis]

While Warren's suggestion is sensible, Mike has a point.

Operators favor simple operating environments and being able to identify a key by a single number is quite simple.

Note though that I've seen multiple keys with the same key_id in use by different TLDs, in each pairing the DNSSEC security algorithm was different.  To wit: key_id 00014 appears as being used by three different operators in three different TLDs over time.  Once as a RSA/SHA1 (NSEC3) from 2016-09-06 to 2017-02-04, once as a RSA/SHA256 from 2018-02-10 and still in use and once as a RSA/SHA512 from 2017-11-04 to 2017-12-05.  (I don't name names, but if anyone wants my data to check into this, send me a request off-list.)

Software developers should (and some might dare say have a responsibility to) implement standards fully/faithfully when the aim is general purpose release of code.  In this case, the data structure for a key matching a key_id is not a scalar (singleton) but a vector (list, array, chain).  When software has failed to be faithful to the specification, operations have had to work around bugs to the point that further work (innovation/improvements) on the protocol is hampered.

Working for ICANN now, I'm not going to commit to any course of action regarding this thread, but I've lived with the idea of making operations simple while keeping software agile for a long time.  This isn't a tradeoff, both ideals can be met.

For example, BIND's dnssec-keygen avoids generating keys with colliding key_ids.  I haven't tested this, but I bet that the validator can handle colliding key_ids.  (Evidence with TLDs suggests that combined with name and algorithm, the same key_id is not an issue.)  I haven't tested this simply because I've not yet generated two keys with the same key_id (and algorithm and name).

As far as the keytag proposal - I don't see a clear way to distinguish between two keys that would have the same key_id (modulo algorithm).  Perhaps just noting that for the proposal is enough and then leaving it to the operator to decide how to act - no matter how the root zone KSK is managed in this regard.  (Noting that the root zone operator is not the only practitioner of Automated Updates of DNSSEC Trust Anchors.)

On 2/20/18, 22:39, "ksk-rollover on behalf of Michael StJohns" <ksk-rollover-bounces at icann.org on behalf of 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.   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
    
    
    
    _______________________________________________
    ksk-rollover mailing list
    ksk-rollover at icann.org
    https://mm.icann.org/mailman/listinfo/ksk-rollover