On 9/21/2014 1:21 PM, Tomofumi Okubo wrote:
Hello Joe,
On Sun, Sep 21, 2014 at 8:41 AM, Joe Abley <jabley@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@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover