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 =-