November 2019 - Comments-proposal-future-rz-ksk-rollovers-01nov19

proposed future rz KSK rollover plan
by John Dickinson Nov. 25, 2019

Nov. 25, 2019

A couple of thoughts… I would like to see a reference to RFC 7958. I know it is on IANA’s Trust Anchor and Keys page. However, since it defines the meanings of some of the terms used in the xml and this document it should be referenced here. I think the validFrom and validUntil fields in the trust anchor file could be more explicitly linked to the stages of this document. I can imagine that a reader might wonder if the validFrom is the start of stage E, D, C or even B as indicated in Section 2.2. Are you sure you mean B? Likewise, validUntil might be end of E or F. RFC 7958 only states that “Relying parties SHOULD NOT use a KeyDigest outside of the time range given in the validFrom and validUntil attributes.” it does not say what “use” means. 2.4 states “Note that the timelines given here are aspirational and not guaranteed. If an event occurs that warrants detailed study before proceeding, the rollover process can pause with the active KSK continuing to be used, even if doing so exceeds the nominal three-year period.” could this cause problems for operators relying on the validFrom and validUntil attributes? It would be nice if the legend in the timeline diagram showed the name of the phase and not the letter. regards John John Dickinson https://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA U.K.

1 0

Re: [Comments-proposal-future-rz-ksk-rollovers-01nov19] [ksk-rollover] Proposal for Future Root Zone KSK Rollovers
by Michael Richardson Nov. 6, 2019

Nov. 6, 2019

Kim Davies <kim.davies(a)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(a)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(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

1 0

Comments on KSK rollovers
by Nicolas Antoniello Nov. 4, 2019

Nov. 4, 2019

Hi, I agree with the 3 year proposal buy have two comments/questions: - According to the Phases and Rollover Cycle table, Phase A is to generate and instantiate the new KSK at one of the two KMFs. Do you take into consideration for the proposed 3 year schedule the alternation of the KMF where the KSK is generated? (that will be to generate the KSK (perform Phase A) alternating in the West coast KMF and then (after 3 years) in the East one, and so over). - Have you take into account the eventual smart card life cycle and the safes lock lifecycle... just wondering if this two events may impact the proposed schedule (as I'm not seeing comments on this on the section 4 (Expected Changes to Processes) of the Proposal. That's all for now :) Best regards, Nicolas Antoniello

1 0