Anyway, Richard pointed out something interesting to me: they plan to roll over the root Zone Signing Key (ZSK) four times a year (see slide 19) which doesn't really make sense to me. Actually, the whole key rollover scheme doesn't make much sense to me.
It might be helpful to start with a little background. The way things are going to work is this: ICANN is going to have a long-lived (2-5 years) Key Signing Key (KSK). The public half of this key will be built into people's resolvers. But the KSK will not be used to directly sign any user data. Rather, it will be used to sign a short-lived (3 months) ZSK [held by VeriSign] which will be used to sign the data. Because the relying party (i.e., your computer) knows the KSK, it can verify any new ZSK without having to get it directly.
Why are they doing this? As far as I can tell the rationale is as follows:
- The security of RSA key pairs is directly connected to key length, which is also the length of the signature that the key pair produces.
- Space in DNS packets is limited.
The combination of these two factors means that if you want to use longer (higher security) key pairs to sign zone data, you start running into size limitations in the packet. That's perfectly understandable, but why does having two keys help. The idea here is that you have a big (2048-bit) and a short (1024-bit) ZSK. But because the ZSK is changed frequently, you don't need as strong a key and can still get good security. I wasn't able to find a good description of this in the DNSSEC documents, but Wikipedia came through:
Keys in DNSKEY records can be used for two different things and typically different DNSKEY records are used for each. First, there are Key Signing Keys (KSK) which are used to sign other DNSKEY records and the DS records. Second, there are Zone Signing Keys (ZSK) which are used to sign RRSIG and NSEC/NSEC3 records. Since the ZSKs are under complete control and use by one particular DNS zone, they can be switched more easily and more often. As a result, ZSKs can be much shorter than KSKs and still offer the same level of protection, but reducing the size of the RRSIG/NSEC/NSEC3 records.
The only problem with this reasoning is that it's almost completely wrong, as can be seen by doing some simple calculations. Let's say we have a key with lifespan one year that requires C computations to break. An attacker buys enough hardware to do C computations in two months and then is able to use the key to forge signatures for the next 10 months (I'll try to write about keys used for confidentiality at some later point.) If we think about a series of keys, they will be vulnerable 10/12 of the time. Now, let's say that we halve the lifespan of the key to 6 months, which shortens the window of vulnerability to 4 months per key, or 2/3 of the time. But if the attacker just buys 2C compute power, he can break the key in 1 month, at which we're back to having the keys vulnerable 10/12 of the time. If we generalize this computation, we can see that if we increase the frequency of key changes by a factor of X, we also increase the attacker's workload by a factor of X.
More concretely, if we originally intended to change keys every 4 years and instead we change them every quarter, this is a factor of 16 (4 bits) improvement in security. Opinions vary about the strength of asymmetric keys, but if we assume that 1024-bit RSA keys have a strength of about 72 bits [*] then this increases the effective strength to around 76 bits, which is somewhere in the neighborhood of 1100 bit RSA keys, a pretty negligible security advantage and nowhere near the strength of a 2048 bit RSA key (> 100 bits of security). It's certainly not correct that this offers the "same level of protection".
The more general lesson here is that changing keys rapidly is nearly useless as a method of preventing analytic attacks. It's almost never practical to change keys frequently enough to have a significant impact on the attacker's required level of effort. If you're that close to the edge of a successful attack, what you need is a stronger key, not to change your weak keys more frequently. In the specific case of DNSSEC, just expanding the size of the packet by 10 bytes or so would have as much if not more security impact at a far lower system complexity cost.