Proposal for Future Root Zone KSK Rollovers
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)
Kim Davies <kim.davies@iana.org> wrote: > 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. I read the document quickly. I used the submit button, which then generated a mailto: URL, bring up in gmail, which I didn't really want to use. Couldn't you just tell me the email address to use? And gmail won't let me copy and paste the email address easily... sigh: I guess it is: comments-proposal-future-rz-ksk-rollovers-01nov19@icann.org I have two comments: 1) In the D and E periods, you have a dashed line, which I think described as the RFC5011 hold-down period. I suggest that you give these two periods a name/number/designation. Maybe D_0 and E_0 or something like that. Maybe a completely new letter. 2) you write: doc> We also propose that each new KSK be generated well before it signs doc> the zone. This will allow a longer period of pre-publication, and doc> consequently allow for the new KSK’s earlier use if there is a need doc> to perform an emergency rollover. As a result, the overall lifespan doc> of future KSKs is anticipated to be about six years — two years of doc> which will be in a standby state (published, but not yet actively doc> used), three years in an doc> active state, and the final year being revoked and then deleted from doc> the key management facilities. Some have expressed concern that the longer the public key is visible the longer a (brute force?) adversary will have to attack the key. I do not entirely concur with this view: if such an attack exists, it exists regardless of when the key is published, and we need to roll the key more often. I'd like to see some discussion of this issue. Still, if there were credible serious concerns here, it seems that there could be a state B-prime, between B and C, or perhaps even from end of A to beginning of C in which a hash of the public key is published, but not the public key itself. Again, I'm **skeptical** about this attack. In particular, software distributions that might sit on the shelf (be burned into CDroms) could embed the hash of the key (K+1) at year Q3 or year Y+3, a full two and half years before the key is in use. (Maybe that would argue for a shorter phase D, and longer state B-prime) I would like to see some feedback (endorsement?) from the RedHat RHEL and Canonical Server LTS managers (and Windows server) about the details of this cycle. I think that the three year KSK cycle with the 2+bit year intro may fit VERY WELL into their release process. The resuling being that, except in emergencies, any LTS image installed within it's support lifespan of typically 5 years, will be able to authenticate the root zone without any additional parts. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On 11/6/19 11:13 AM, Michael Richardson wrote:
I guess it is: comments-proposal-future-rz-ksk-rollovers-01nov19@icann.org
Yes. But we do like people to click through to agree to the submission rules.
I have two comments:
For the benefit of this mailing list: comments sent to this list are not considered as part of the public comments on this proposal. Michael Cc'd the email address for his comments, so they should appear there. We (ICANN) need the comments to be in the public archives of the address given above so that they can be seen by the rest of the community and collected at the end of the comments process. --Paul Hoffman
participants (3)
-
Kim Davies -
Michael Richardson -
Paul Hoffman