[dns-wg] KSK lifetimes

At 14:58 +0000 2/5/10, Jim Reid wrote:
>On 5 Feb 2010, at 14:18, Ralf Weber wrote:
>
>>  With the root planning for much longer time frames on KSK rollovers
>>  maybe RIPE NCC should think about increasing it's KSK life times.
>
>Ralf, I don't follow you. Could you please explain why the NCC should
>increase the lifetime of its KSKs?

I do not read the message as suggesting that the RIPE NCC match the 
root zone key management parameters.  Instead I read that "there's a 
new data point available on what the parameters for key management 
should be, so maybe it is a good time to rethink the RIPE NCC 
parameters."

>Just because "the root's going to have long KSK lifetimes" isn't an 
>answer. :-)
Maybe it is.  Odds are that the work being done to sign the root is 
being carried out by a top-notch staff of individuals - if they 
emerge with some surprising results, it's worth looking into why. 
But you are also right, there's no need to match the results.

>I'd like to hear the reasoning why key management by the NCC should be the
>same as that for the root, particularly if it goes beyond the usual "if it's
>good enough for the root, it's good enough for me". FWIW, I regularly make
>that case when people ask me what DNS software they should run.

Frankly, it's far easier to make the case why not.

>What I do think would be helpful is a document explaining how the eventual
>parameters were chosen and the trade-offs/thinking that went into those
>choices. This is needed for DNSSEC generally as well as for the root zone
>and the NCC's bits of the .arpa tree.

The reason I jumped in with this reply is that in the last month or 
so there was an interesting thread in the IETF about the relationship 
of key size and key effectivity periods.  (I.e., is a key of 1024 
bits good for a year, a key of 2048 good for 2?)

The outcome of the thread was that, if left up to the cryptographic 
issues, there would be no need to change keys until a key was 
detected as being broken.  This is because the effective lifetime of 
a key is not determined by the key itself but rather by the 
determination of the attackers.  The moral - you only need to change 
the key in an emergency.

But, as a good operator you know that you never do anything in an 
emergency you don't do on a regular basis - whether that means 
regularly exercise the plan in production, in practice, or in drills. 
So, the parameters for key change fall under the domain of 
operational cycles and not cryptographic considerations.

And, for operators in large organizations, "regularly" means on a 
strict periodic schedule (such as monthly) - something that can be 
easily programmed into cron.

The realization that it isn't the cryptography limiting the 
usefulness of the key to me is "new thinking."  All along I thought 
that the limitation on the effectivity of a key was the cryptography 
- but for "good enough keys" the limitation is how comfortable I am 
going without changing it and how much does it cost to change it.

Based on that discussion, and the fact that root zone is willing to 
use longer term keys, I'd rethink the 6 month changes of the KSK.  Or 
maybe just because the root will be signed soon and the RIPE NCC 
DNSSEC keys will ultimately be chained from there (modulo the reverse 
map's intermediate zones).  Further, when we automate all of the 
registration interfaces, the cost/pain of rolling the KSK goes to 
almost 0 - maybe frequently change it.  OTOH, if we only have to 
worry about attacks and abuse, maybe we hardly ever change it.

As we progress operationally with DNSSEC, we will be learning a lot 
more.  There's no shame in being the first out the door and then 
learning you can or should adjust your parameters based on the 
follower's experiences.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.