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.