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

David Conrad david.conrad at icann.org
Mon Sep 22 14:29:36 UTC 2014

On Sep 21, 2014, at 11:37 PM, S Moonesamy <sm+icann at elandsys.com> wrote:
> It seems that the CA business is being conflated with Root DNSSEC.


> There is supposed to be redundancy as part of the DNSSEC practice to reduce the risks.  The HSMs are offline.  The risk there is physical access [1].  An emergency roll-over could, in simple terms, be when a private key is lost or compromised.  A planned roll-over reduces the likelihood of that happening.  

If the risk is physical access, then the implication of a planned rollover is that that physical access occurs (much) more frequently than if the physical access is limited to the times when emergency rollover is needed.  As such, it actually increases the likelihood of it happening. What a planned rollover does do is provide more experience in the hopes that we can recover more easily.

Of course, if the private key is lost or compromised, you can’t use 5011 for a rollover.

> The reluctance to do that planned roll-over is probably because:
>  (a) It has never been done before.

No. We never signed the root before, yet we did that.

>  (b) There will be an operational impact.

Repeating part of a previous message:

"(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."

> It is difficult to assess (b) because of (a).  What there is now is "the root key" [2].  It is not a good idea, in my opinion, to have "the root key"[3].

I agree that having a single key (shared or not) is not ideal. However, current limitations in algorithms/lengths imply some risk of resolver failure if multiple keys are used.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20140922/794d8306/signature.asc>

More information about the ksk-rollover mailing list