[ksk-change] planned vs. emergency (was Re: [ksk-rollover] root zone KSK ...)

[Olaf Kolkman]

On Sep 22, 2014, at 4:29 PM, David Conrad <david.conrad at icann.org<mailto:david.conrad at icann.org>> wrote:

"(a) there is no operational reason that forces the key to change, (b) there is a risk — no matter how slight — that we might screw up, (c) it is expensive and time consuming to drag the necessary people into the secure facilities to spend the 2+ hours necessary to do the key handling appropriately, and (d), it is likely that rolling the key _will_ break things, the only question is how much and who will be affected.”


I believe that the argument to roll to make sure bad operational habits are not ossified (paraphrased from RFC6771) is an operational reason (I’ve pasted it below for reference). So I do not (fully) agree with (a). I would agree if you would say inherit operational reason.

The question is really what sort of breakage (and associated costs) do we accept now versus when we do have an inherit operational reason. I believe, but that is not very helpful I realize, that by accepting some breakage today (mainly accepting (d)) we will reduce the fraction of folk that suffer (d) in the future.  At some point that argument will not hold because the amount of people in the (d) category are to many or more than only a number of early deployers that still track the technology developments.

—Olaf

RFC 6781 3.2.2:


   However, the "operational habit" argument also applies to trust
   anchor reconfiguration at the clients' validators.  If a short key
   effectivity period is used and the trust anchor configuration has to
   be revisited on a regular basis, the odds that the configuration
   tends to be forgotten are smaller.  In fact, the costs for those
   users can be minimized by automating the rollover with RFC 5011<http://tools.ietf.org/html/rfc5011>
   [RFC5011<http://tools.ietf.org/html/rfc5011>] and by rolling the key regularly (and advertising such) so

   that the operators of validating resolvers will put the appropriate
   mechanism in place to deal with these stability costs: In other
   words, budget for these costs instead of incurring them unexpectedly.



— — — — — — — — — —
Olaf Kolkman
(on personal title)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20140922/c6da05a1/attachment-0001.html>