On 15/02/2018 01:36, Geoff Huston wrote:

...

On 15 Feb 2018, at 8:35 am, Paul Hoffman <paul.hoffman@icann.org> wrote:

On Feb 14, 2018, at 12:40 PM, Warren Kumari <warren@kumari.net> wrote:

...

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. If is *does* have the same Key ID, it should be discarded and a new one generated.

As someone who has to write tools to deal with ICANN's trust anchors, I give this proposal two thumbs up.

Warren has done well to point this out, and yes, its a small but important aspect of the key generation process

I raised the issue of keyid collission also once at the mic, and from what I remember someone (from ICANN?) mentioned that at any time a (new) unique keyid will be generated. But I fully agree it is important to explicitly mention this in the key generation procedure (ceremony/protocol). Cheers, -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/

Hello All, I will apologize upfront. I am trying to follow all the threads to keep up. I want to make sure the key beginning with "AwEAAaz/" and ending with "UTV74bU=" is the new KSK key that need to be in place for rollover. The last question has made me feel there is a new key being generated. Is this the case? Again, I do apologize if am off but I want to make sure I have the correct key in place. Thank you clearing this up for me. On Wed, Feb 14, 2018 at 4:37 PM, Andres Pavez <andres.pavez@iana.org> wrote:

Hi Warren, Thanks for your suggestion, it is something that we may considering including in the script section relating to key generation.

Anyway, the current software that is used to generate keys (kskgen) ensure the use of a unique random label of the newly generated key.

https://github.com/iana-org/dnssec-keytools/blob/master/kskgen/kskgen.c

Thanks, -- Andres Pavez Cryptographic Key Manager

On 2/14/18, 12:41, "ksk-rollover on behalf of Warren Kumari" < ksk-rollover-bounces@icann.org on behalf of warren@kumari.net> 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover

_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover

-- Sameka S. McNeil Information Technology Specialist Phone: 301.628.5644 Cell: 202.360.9428

Paul, Thank you for clearing that up for me. Much appreciated. On Thu, Feb 15, 2018 at 10:52 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:

On Feb 15, 2018, at 5:51 AM, Sameka McNeil - NOAA Federal < sameka.s.mcneil@noaa.gov> wrote:

...

I will apologize upfront. I am trying to follow all the threads to keep up. I want to make sure the key beginning with "AwEAAaz/" and ending with "UTV74bU=" is the new KSK key that need to be in place for rollover.

It is.

...

The last question has made me feel there is a new key being generated. Is this the case?

Not soon, we hope. But one will almost certainly be generated in future years. This thread is about the procedure for future keys.

--Paul Hoffman

-- Sameka S. McNeil Information Technology Specialist Phone: 301.628.5644 Cell: 202.360.9428

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@icann.org on behalf of msj@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@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover

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

On Feb 21, 2018, at 2:28 PM, Geoff Huston <gih@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

On 2/21/18, 15:25, "ksk-rollover on behalf of Michael StJohns" <ksk-rollover-bounces@icann.org on behalf of msj@nthpermutation.com> wrote:

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.

No need to fret...Roy (and others) to the rescue: http://iepg.org/2016-04-03-ietf95/keytags.pdf or, well, see slide 40...

*bleah* Mike

Someone's *bleah* is someone else's "Oh yeah!" ;)