- ksk-rollover - lists.icann.org

Rollover 2.0?
by Shane Kerr March 14, 2022

March 14, 2022

Hello, It's been 3.5 years since the root KSK roll (2018-10-11). Since the idea was to roll it every 5 years, I guess that preparation for the next roll should be starting right? What's the status of that? Cheers, -- Shane

3 2

Staff Report on Future Root Zone KSK Rollovers
by Kim Davies Aug. 7, 2020

Aug. 7, 2020

Our staff report on the public comments received in our root zone KSK rollover consultation has now been posted. Please find it attached for your convenience. As noted in the report, we are continuing to monitor the COVID-19 pandemic and its operational impacts before we can better commit to a specific schedule. We are also kicking off PTI and ICANN’s next budgeting cycle and will propose allocations to support research work that was suggested in the comments we received. kim

1 0

some simple/silly questions about root KSK ceremonies
by Michael Richardson July 13, 2020

July 13, 2020

Three questions: 1) Should I refer to https://www.iana.org/dnssec/icann-dps.txt or https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf as the authoritative document? The first is clearly more recent, and seems better linked. But, maybe it's a draft. 2) With the April 23 ceremoney (#41) having been held, would there there not have been another in July? What will happen? It seems that maybe enough things were signed in April to last awhile. 3) There was a long debate about how often to roll the root key. A link to: https://www.icann.org/public-comments/proposal-future-rz-ksk-rollovers-2019… was posted last fall. I see that the report is still overdue. I was looking for something authoritative to cite. Is it reasonable to cite: https://www.icann.org/en/system/files/files/proposal-future-rz-ksk-rollover… for now? -- Michael Richardson <mcr+IETF(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

2 2

ceremonies in April, and managing things less critical and the KSK.
by Michael Richardson April 6, 2020

April 6, 2020

I was locating appropriate references for explaining Key signing ceremonies, and noticed the report of the safe problems at: https://www.theregister.co.uk/2020/02/13/iana_dnssec_ksk_delay/ https://www.icann.org/news/blog/root-key-signing-key-ceremony-postponed and then the schedule at: https://www.iana.org/dnssec/ceremonies in which April 23 is the next date. Will travel bans cause a problem? I kinda hope the travel bans are enforced. "Introduce HSM6E" Does this mean that a new HSM device will be added? I see RRSIG from keyid 20326 (current root) will expire 20200422000000. Maybe there is another RRSIG hidden away that I can't see? https://www.iana.org/dnssec/icann-dps.txt I am unclear from reading things over again how the ZSK gets to the ceremony. Is a new ZSK keypair generated during the KSK, or is it generated elsewhere and only the public part brought? But, I started re-reading things because I was looking for pointers to documents *less* secure practices for CA key management. That's poor wording. let me try again: Practices for lower value assets than the KSK. -- Michael Richardson <mcr+IETF(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

6 11

Starting date for the proposed root zone KSK rollover scheme
by Chris Thompson Feb. 9, 2020

Feb. 9, 2020

I appreciate that the period for official comments on the new framework has closed as of 31 January, but if I were to make an individual submission it would perhaps concentrate on the following point. Other issues (algorithm rollover, standby keys, emergency rollovers) have been well covered in existing submissions. No specific date is proposed for starting up the new scheme, perhaps to avoid appearing to assume community acceptance in advance. If stage A for the next KSK occurs in 2020Q2, this should lead to a planned rollover on 11 October 2022, four years after the previous one. If the other matters are to be postponed for consideration only in subsequent rollovers (which does seem reasonable) then this schedule is acceptable, but any further delay is to my mind undesirable. This would imply work to be done to generate the new KSK as part of the key ceremony already announced for 23 April 2020. I would urge ICANN to proceed on that basis, even if there remains some contention about the new scheme at that time. It would not be necessary to advertise the new KSK in any way at that stage - indeed, it could be removed from the KMF again subsequently if there was a decision to use some other incompatible scheme. -- Chris Thompson Email: cet1(a)cam.ac.uk

1 0

Proposal for Future Root Zone KSK Rollovers
by Kim Davies Nov. 6, 2019

Nov. 6, 2019

Colleagues, We would like to share that our Proposal for Future Root Zone KSK Rollovers has been published for public comment and is available for review on the ICANN website: https://www.icann.org/public-comments/proposal-future-rz-ksk-rollovers-2019… We have reviewed the feedback received from the community, and tailored a plan based upon community feedback, operational complexity, and lessons learned in the first KSK rollover projects which concluded recently. From a high level perspective, the plan includes a three-year rollover interval, with a period of about two years in a standby state before the rollover and active phase of the KSK. The proposal outlines the future KSK lifecycle which will directly affect activities in future KSK ceremonies, and the frequency in which different HSM smartcards are required. Please take this into consideration along with the HSM lifecycle in conjunction with the proposal for credential re-issuance. The three-year rollover strikes a responsible balance ensuring that procedures and software remain sufficiently agile to adopt new keys as they are commissioned, while not introducing too much operational complexity through overly-frequent changes to the KSK. The standby period will allow a longer pre-publication and consequently allow for the new KSK’s earlier use if there is a need to perform an emergency rollover. The public comment period is slated to close at the end of January. We encourage you to submit your feedback so we may integrate it into the final approach. For those at the ICANN 66 meeting in Montreal this week, we will be presenting the proposal to the DNSSEC session being held later today. Kim Davies VP, IANA Services, ICANN President, Public Technical Identifiers (PTI)

3 2

Next rollover planning?
by Michael StJohns Oct. 16, 2019

Oct. 16, 2019

Hi - I haven't seen anything on this list for planning for the next rollover. Perhaps we should start now? Later, Mike

2 1

Retention of the 2010 KSK
by Kim Davies Sept. 25, 2019

Sept. 25, 2019

Just confirming my mic comments: Our current schedule has us remove the 2010 KSK from our HSMs in one of our two key management facilities in May, and from the HSMs in the other key management facility in August. While perhaps not a complete specification, we’d need a strong indicator we need to retain the KSK longer ideally by May, and certainly no later than August, in order to defer the deletion and retain the capability to use it (i.e. to create a signature via a new mechanism that would endorse the subsequent KSK). kim

13 24

IoT devices and KSK rollover
by Michael Richardson July 2, 2019

July 2, 2019

ICANN has a document at: https://www.icann.org/en/system/files/files/sac-105-en.pdf about IoT and DNS, opportunities and risks. (I liked that it had both). One point is: > 5.1 Developing a DNS security and transparency library for IoT devices > The first challenge is developing and maintaining an open source DNS > security library that makes functions like DNSSEC validation, DANE, and > DoH/DoT available on IoT devices. The library would need to include > transparent support for routine root KSK rollovers, such as automatically > changing keys and notifying the DNS of which KSK an IoT device is currently > using [45]. This will likely be more challenging than with traditional > resolvers, partly because it may not be possible to remotely update IoT > devices, and many IoT devices lack the non-volatile storage necessary to > store keying material. While the points in the last sentence are certainly true, they aren't particularly relevant. Keys are not that big compared to the code to use them. More and more often, IoT devices are updateable, the issue is that they can't really be updated if they are turned off, in a warehouse. Despite what other parts of the document suggest, I don't think that DoH is a useful thing for IoT. I think actually the opposite, but this section seems to suggest that someone, ICANN?, will be considering funding or doing some software development to make a useful validating stub resolver work in an constrained device. (OpenWRT is not really that code constrained, RIOT-OS is). I am bringing this up here, because I think that there is an opportunity here to *define* (to lead) on how to do IoT with DNSSEC and tolerating long-term offline storage. That is, if I understood this SSAC ICANN document's point. There are a multitude of ways to do this, and we have discussed this, but let me repeat the two major paths: 1) a way to upgrade from the KSK known at the time of manufacturer to today's key. -or- 2) a way to reliably (without being easily spoofed), turning off DNSSEC validation long enough to search out, and get a firmware update that has the today's keys. ---- The document goes on to talk about training, and while this part is not particularly KSK relevant, I wrote another email about this document about IoT and DNS and MUD, I think that it's worth repeating here. > * Training IoT and DNS professionals (Section 5.2) to help DNS players such > as registrars and registrants understand the implications of providing > services for domain names that act as a backend for IoT devices rather than > as a means for making content available to humans (Section 3.3), and to > help IoT device manufacturers understand how to use the DNS and how to > configure resolvers (Sections 4.1 and 4.3). I think that there is a missing element here, which is talking about DNS at IoT conferences, about the libraries one can use, but most importantly, about how to do DNS in a way that makes MUD easier to do. There is also a need to reach out to the CDN community, and deal with the question of names to IP mapping, and how we make sure that the name provides the service requested, and only that service. -- Michael Richardson <mcr+IETF(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

7 11

Re: [ksk-rollover] IoT devices and KSK rollover
by Paul Wouters July 2, 2019

July 2, 2019

On Mon, 1 Jul 2019, Michael Casadevall wrote: > As for DoT/DoH, none of the above changes as there are no wire protocol > changes to DNS in either of these use cases, and the cost of > implementation is stupidly high. First off, it's impossible to deploy > DoT/DoH in an internal network that uses RFC1918 address space (aka > 10.0.0.0/8, 172.16.0.0/20, 192.168.0.0/16) as CA/B forum CAs can't issue > certificates for this address space; what prevents you from requesting a certificate on an internet connect IP using ACME, and then moving or also using it on the internal IP pointed to by internal only split DNS ? > Device manufactors also need to update their devices to update > their root store from time to time. I guess it really depends on your definition of IoT. > It should also be noted that the current Mozilla NSS root store is > approximately 250 KiB in size uncompressed. Why would an IoT device need the whole firefox or other vendor root CA store? Again, it really depends on what you call an IoT device. > There are major issues with DoH/DoT in general, but a lot of devices in > general are going to simply incapable of supporting it because the cost > of full TLS support + full set of CA root certificates is simply too > high in terms of flash storage. Maybe IoT devices shouldn't need to talk to the internet at large? And their trust model can be minimzed to the little things it needs? Paul

4 3