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

[Michael StJohns]

On 9/18/2014 6:25 PM, Paul Hoffman wrote:
> 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.)

Hmm...  I said that A said B, but that what I thought he meant (because 
I thought B was a bit overreaching and not necessarily true in all 
circumstances which I didn't actually mention at the time) was C which 
is a proper subset of B. .   Strangely enough C is pretty much "there's 
no reason to roll the KSK key just due to key strength lifetime issues" 
which is what you just said below, but in a less roundabout way.

And just to be clear... I actually think "C" is correct/not stupid. I 
went back to my original email, and nowhere did I find the "C is stupid" 
statement either explicit or implied.


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

The way I said it.  You used the phrase "cryptographic reasons" which 
AFAIK is not a term of art.  So the plain language meaning is "reasons 
related to cryptography" which cuts a very very large swath.    
Basically, I disagree with you on your statement that it's a given 
"there are no cryptographic reasons" to roll the key.  I re-wrote what 
you put out into a statement that I think mostly matches what most of us 
believe as "given" - that the current KSK key material is probably not 
vulnerable to cryptographic attacks during its probable lifetime even 
without rolling - but that's only one small "cryptographic reason".


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

That's an interesting definition.  But not one that I would give much 
credence to.  A rollover is nothing more than replacing one key with 
another.    Replacing an RSA key with an EC key is still a rollover.  In 
this particular instance, the issue with doing a key/signature type 
change as part of a key rollover has more do to with the limitations of 
the acceptors (the validating resolvers and clients) than with an 
artificial distinction between replacing an RSA2048 bit key with a key 
of the same type vs an EC key.

We have three choices basically: don't roll the KSK; roll the KSK and 
replace it with a key of the same signature type; roll the KSK and 
replace it with a key of a different signature type.

And even that isn't exactly correct, as what we're really talking about 
doing is first adding keys to the root trust anchor set, and then 
removing keys from that set.  It's really not quite the same as rolling 
a ZSK (due to 5011 timing issues).


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

If you don't like the selection of reference material, pick another 
something.  But make it peer reviewed by experts, widely accepted and 
generally available.  The NIST documents meet those criteria.

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

I'm not quite sure what you're getting at here.  DNSSEC pretty much 
makes it impossible to change a signature algorithm without changing a 
key, so changing the signature algorithm used in signatures over the 
root DNSKEY RRSet is going to require first a) adding a trust anchor key 
with the new signature algorithm, b) signing the DNSKEY RRSet with that 
key/algorithm, and c) eventually phasing out the old trust anchor keys 
and signatures.

Later, Mike


>
> --Paul Hoffman