Apologies in advance for the longer than intended reply. I've spent a lot of time reviewing documents regarding timing values and they vary quite widely. One observation I've made is that many recommendations, especially those that are a little older, are predicated on the assumption that the process of signing is difficult and complicated. So last year I saw recommendations of ZSKs for a year and KSKs for 2 or more. As signing became easier and TLDs made their submission policies for DS (or pub key) clearer these numbers have dropped.
I'm now seeing recommendations of 1-3 months for ZSKs and 6-12 months for KSKs. If you automate it, which is relatively easy today, then having shorter times makes sense on a number of levels. -It allows potentially lower bit sizes, due to the time/size trade off. -It ingrains the process within your operational procedures. Really large gaps between events can lead to a loss of skills or capability. (has anyone seen that HSM we bought 2 years ago?). That may or may not happen of course, but its good to exercise procedures. -You can use roll over times as natural change windows for new algorithms or new procedures. And the likelihood of changes in the next 2 years is very high since registries are still adapting and learning. The value of the above benefits will vary depending on how many domains you have across how many different TLDs. The more of either, the greater the benefit of an automated and reasonably regular roll over. Online/offline keys Sometimes this may be a choice, other times legislative or standards compliance will require certain behaviour. I've seen some documents require that even ZSKs remain offline (government agencies mostly), but generally its not considered much benefit if it rolls over reasonably often. KSKs are more commonly recommended to remain offline, but that definition can vary as well. A genuine HSM (Hardware Security Module), is not likely to be found in the bulk of DNSSEC deployments, due to cost, complexity and operational staff skills. Thus most operations will find it easier to generate keys either on the master server (perhaps the only server with key generating software) or close by (another server that is nevertheless "online"). If you don't use an offline HSM, then your alternatives will require you to have shorter roll over times in my opinion. Regarding algorithms, you're likely to need 2 if you wish to use SHA 512 (or anything that isn't SHA1). My recollection on this may be wrong, but SHA1 is still required for DNSSEC I believe. So keep that in mind when staggering roll over times. Finally note that the blog on ISCs website regarding 9.7.2 foreshadowed some automated and sane timing controls: http://www.isc.org/community/blog/201006/bind-972-and-and-automatic-dnssec-s igning I've seen no recommendations regarding NSEC3 salt lifetimes, but if you automate key generation (balanced by shorter lifetimes), you could change the salt as you re-sign. On 17/09/10 8:26 PM, "Niobos" <nio...@dest-unreach.be> wrote: > Hi, > > I'm playing around with the different timers of DNSSEC. Usually these > timers are a balance between a low overhead vs quick propagation: > * A high TTL gives more caching and thus less load on the authoritative > server; but it takes a long time for updates to propagate. > * A short RRSIG lifetime limits the amount of time old answers can be > replayed; but requires regular resigning > > Or they are a balance between low overhead and security: > * A DNSKEY (ZSK or KSK) used for a long time risks being cracked; > changing it often requires maintenance. > > But for the NSEC3 salt, I can't really figure out what the components > are... If someone is brute-forcing the NSEC3 hashes (cfr Daniel > Bernstein's presentation), changing the salt requires only a minuscule > change on their end. I see no reason to change the NSEC3 salt at all. > > So the question is: what is a normal lifetime of an NSEC3 salt, and for > what reason? > > And while I'm at it: what lifetimes, keylengths and algo's are popular > for ZSK's and KSK's? Are your keys stored online or offline? > > I'm thinking of using ZSK's of 1280bits for a year (since I'm lazy) and > KSK's of 2048bits until I feel like changing it (i.e. pretty much > indefinitely). This would allow the KSK to be offline, and only needed > once a year. > I'd like to use NSEC3 with RSA/SHA-512, but that might be unreasonable > strong compared to my lazy lifetimes. On the other hand, RSA/SHA1 is > more compatible (eg with bind 9.6). > My signature lifetime will probably be 3 weeks, resigning every week. > With 1 week expire timers, it leaves 1 week of margin to correct errors. > Are these values/argo's sane? > > Thx, > Niobos > > PS: don't try talking me into using NSEC. I'm using NSEC3 "because I > can", not that it would be any problem at all if they walked my zone. > > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users