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

[Michael StJohns]

On 9/21/2014 1:21 PM, Tomofumi Okubo wrote:
> Hello Joe,
>
> On Sun, Sep 21, 2014 at 8:41 AM, Joe Abley <jabley at hopcount.ca> wrote:
>
>> Having such a standby key available (e.g. as recommended in RFC 5011, and by Mike StJohns in the past)

Heh... since I wrote 5011, you might expect those to be similar.
>>   would help align the two procedures, although an approach for mitigating the compromise of both active and standby keys would still be required for the general case of emergency roll due to compromise.
> Yes I agree. I like the idea of having standby keys that will help a lot.
>
> Although, even with the standby keys, we still need to consider
> scenarios in which both keys needs to be replaced such as algorithm
> compromise (if it is the same) or physical compromise of the key (if
> both key sit on he same HSM).

Worst case is compromise of all trust anchor keys.  5011 allows you to 
recover from an N-1 compromise (where you have at least one private key 
associated with the root trust anchor set that hasn't been 
compromised).  Absent DNS size limitations, you could set N to be 3 or 4 
and sequester the N-1 standby private keys in a manner to minimize their 
compromise.  The probability of a catastrophic worst case is then

Psecure = 1-PRODUCT[for each key](1-Psecure[key]))

Say the probability for an active key to stay secure over 10 years is 
99% and for a stand by key is 99.9%.  For a three key system with two 
keys in standby, then the math is 1-(.01 * .001 * .001) or a 99.999999% 
chance of keeping the system secure for 10 years.

Of course the hard part is crafting protections to give you those chances.

Later, Mike


>
> Thanks,
> Tomofumi
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover