[ksk-rollover] root zone KSK rollover operations workshop planning

[Michael StJohns]

On 9/18/2014 10:30 AM, Paul Hoffman wrote:
> On Sep 18, 2014, at 12:17 AM, Peter Koch <pk at denic.de> wrote:
>
>> great, many thanks for taking the lead and organizing this.
>> Without bothering this list with layer 9 issues too much, and at the
>> very high risk of having missed previous discussion on the issue,
>> where can I find some info on the group/org(s) behind this, a timeline and
>> the intended way of decision making (to the extent applicable)?
> +1
>
> Given that there is no cryptographic reason to roll the KSK under the current policies,

Whenever someone uses "Given" to imply there's no go reason to do 
something, I tend to try and parse what the writer actually was trying 
to say.

In the above, I would think to translate this as "Given that the 
cryptographic properties of the key material we're using for the KSKs 
has sufficient strength to resist attacks on the cryptography for the 
foreseeable future we have no reason to roll the KSK due to time-outs on 
key material strength" which is what I think Paul meant.

His original statement could be read to imply that  "cryptographic 
reasons" like wanting to shrink signature lengths (e.g. rolling an RSA 
key to an EC key) don't exist.

>   it would be good to have a list of the perceived operational reasons to roll the KSK. With that, we can come up with a better argument for the timeframe.

I found this one also written a little too tightly as well.  I'd do:

"It would be good to have a list of reasons, beliefs, standards of 
practices, expert guidance and anecdotal experiences either directly on 
point or with analogues to the DNS system which touch on whether or not 
its a good idea to roll the KSK"

So a good place to start IMHO is NIST SP800-57 Part 1, Rev 3, Section 
5.3.4 Cryptoperiods for Asymmetric Keys.

Other places to look are:

  a) What is the expected EOL of the hardware currently used for root 
signing?
     i) Is there a transition plan for transition to new hardware?
     ii) Is the expected security EOL of the hardware earlier than the 
actual EOL of the hardware (e.g. have hardware attacks improved such as 
to weaken the security of the root key at rest in the HSM?)
b) What affect on the overall security of the system does transition of 
personnel have?  E.g. replacement of ICANN personnel involved with the 
KSK, replacement of community representatives?  Are there exploitable 
attack surfaces?
c) What is the expected impact on security if funding for the KSK 
function were reduced or interrupted for a period of time or permanently?
d) What is the expected impact on security if the KSK is compromised, 
and we have no way of rolling the KSK? (e.g. single KSK in root zone).  
Is there an additional real-world cost to end users in this event?

e) Can any of the above be mitigated through a single KSK rollover? 
Through regularly scheduled KSK rollovers?

This is where I'd go with the "should we do it" analysis.

Later, Mike


>
> --Paul Hoffman
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover