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

David Conrad david.conrad at icann.org
Mon Sep 22 02:55:27 UTC 2014


[snipping for brevity, not necessarily agreement]

On Sep 21, 2014, at 4:54 PM, Michael StJohns <msj at nthpermutation.com> wrote:
>> a. for all intents and purposes, the likelihood of _any_ compromise/loss of the root key is statistically equivalent.
> Bad assumption. [...]  So if you have a 1 in a million chance to compromise one key, and the probability is similar between all keys, the probability of compromising the SYSTEM if you're using 2 keys is 1 in a trillion and 1 in a quintillion for 3 keys.

If the risk of compromise is constrained to key handling (which I gather you are assuming), given the processes and frequency of key use, then I will again assert that the probability of compromise of 1, 2, and 3 keys is pragmatically speaking, statistically equivalent and essentially zero. Even 1-in-a-million failure rate when you exercise the system once a quarter is beyond any reasonable timeframe that we might consider.

Out of curiosity, how do you deal with the keyset size issue?

> OTOH dealing with less than catastrophic single key compromises seems to be well within the possibility of automated and secure and is exactly what 5011 was designed to accomplish.

You appear to have much more faith than I that code will operate as intended when it is exercised with a frequency appropriate to dealing with critical infrastructure.

Or do you believe we should revise the key handling policies and processes to roll _much_ more frequently?

>> c. touching the root key for any reason increases the probability of catastrophic failure/compromise by an infinitesimal but non-zero amount.
> No.  Touching the *only* root key does that. Touching one root key where the others are locked away decouples the fate of the system from the fate of the key.

It does NOT fully decouple the fate of the system since you have to begin using the locked away key, which means you have to exercise (likely little used) processes and place that formerly-locked away key into use.  All of that increases risk “by an infinitesimal but non-zero amount”.

>> d. changing the root key of the DNS is and will continue to be an infrequent event (both because of (c) but more likely the PITA-ness of changing the key).
> This is a circular argument, we won't change the key, because we haven't changed the key because its painful to change the key so we wont' change the key.

No. We won’t change the key frequently because (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.

5011, at least theoretically, gives us the ability to roll the key frequently and/or for non-crtical reasons. However, given operational realities, it isn’t clear to me that is necessary/useful/helpful. Since we have to deal with a “full trust reboot” and that provides a superset of functionality to 5011, I’m still unclear as to why we care about 5011.

>> P.S. An honest question: how often do root X.509 CAs roll their root keys?
> It's kind of irrelevant, but somewhere between 5 and 20 years.  

I’ve been told (informally) the X.509 root CAs do not roll their root keys, period. It might be useful to get an authoritative answer on that question.

> It's irrelevant since there are something like 50+ of them in common use

If you’re one of those CAs and your root’s private key is compromised, the fact that you have 49 competitors is unlikely to be much of a consolation.  The point being that from the perspective of the CA, the loss of the key is an existential risk and your policies and processes are designed to deal with that risk. I see some parallels in the handling of the root key. It might be useful to understand how the CAs deal with that risk.


-------------- 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/5710d8d6/signature-0001.asc>

More information about the ksk-rollover mailing list