On Wed, Oct 7, 2009 at 6:22 AM, Joe Abley <[email protected]> wrote: > [from a namedroppers thread, re-pointed as per Olaf's suggestion below] > > On 2009-10-07, at 09:23, Olaf Kolkman wrote: > >> On Oct 6, 2009, at 10:08 PM, Eric Rescorla wrote: >> >>> I don't have a general position on ZSKs--perhaps it's a good idea for >>> some other reason--but I don't >>> think that rolling the keys over at high rates provides any >>> significant security benefit, no matter >>> where in the hierarchy you're doing it. >> >> Really this is an DNSOP issues, more specifically an issue for RFC4641bis. >> >> [I've added dnsop, please remove namedroppers when replying to this note] >> >> RFC4641 argues for frequent ZSK rollovers, the argument therein is >> based on operational arguments that are (implicitly) based on operator >> acces to private keys and/or the timeline in which changes in which >> the (zone) operator may need to be replaced. > > I skimmed through 4641 to try and refresh my memory, but couldn't find the > discussion on ZSK rollover frequency. No doubt this is my deficiency. > > From my perspective the operational argument is that procedures which are > rarely exercised may not be exercised well when they are needed (a backup > that is not regularly tested cannot really be relied upon; a protect path > that is never used might not work when it is needed, etc). > > Frequent key rollover has the operational benefit of when you need to do an > emergency roll you know the procedures work.
I see this argument, but I'm not sure I buy it. Because DNSSEC has no concept of revocation list or online revocation, keys remain valid until they expire, so lifetimes must be short (I don't think 3 months is crazy here, though I would have been tempted to go even shorter). This means you will be regularly signing new ZSKs, even if the new ZSKs are the same as the old ZSKs. This will exercise most of the relevant code and some of the procedures. Similarly, because there is no way to do immediate key revocation, you're stuck with having the compromised key valid for weeks or months, so it's not like you don't have time to figure out the rest of the procedures if you don't have them exactly right. > From this perspective we might roll a ZSK more frequently than a KSK because > the ZSK needs to be stored on-line to facilitate re-signing when the zone > changes. With the KSK we have the option of keeping it off-line, and > arguably the risk of compromise is consequently lower. Regular testing of > the machinery is still important, however. Again, this seems like an argument for the ZSK/KSK split, which I'm not really arguing against (I haven't developed an opinion). My argument is purely against generating a new ZSK every time you sign it with the KSK. I don't think that provides much security benefit and certainly does have plenty of room for error. -Ekr _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
