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

[Paul Hoffman]

On Sep 18, 2014, at 8:58 AM, Michael StJohns <msj at nthpermutation.com> wrote:

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

It is not. (Hint: "A said B, which I assume means C which is stupid" is not a popular method for discussions in the IETF.)

The current policy is to have the KSK be 2048 bits and the ZSK be 1024 bits. There is ~30 bits of effective strength difference between those. You would be literally insane to attack the KSK. If you had the resources to break the KSK, you could break a ZSK a billion times faster. The lifetime of a ZSK is six months. If you attack the KSK, you are assuming that you have literally 500,000 years to do so; otherwise attacking the ZSK would make more sense.

Said another way, if we are worried about an attacker who can break the KSK in 100 years, we should be more worried that the same attacker could break the current ZSK in about 3 seconds.

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

Or it could be read to imply that we do not assume that attackers are so insane that they would attack the wrong key. Which way do you think is a better way to read what I said?

FWIW, the question of changing key type (which I strongly support) has nothing to do with a KSK *rollover*.

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

I prefer more concise questions, but your list seems fine too.

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

Only if you are literally insane. :-)

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

I would add:

f) If there is a plan to change the signature algorithm, does that fact affect the need for the KSK rollover? If so, how?

--Paul Hoffman