> Date: Mon, 20 Sep 2010 11:03:31 +0200 > From: Kalman Feher <kalman.fe...@melbourneit.com.au> > Sender: bind-users-bounces+oberman=es....@lists.isc.org > > 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.
The advice on this has always been all over the map, but the most common recommendation I have seen, and I have been seeing it for years, is to roll ZSKs about once a month and KSKs annually. I recommend anyone attempting to secure their DNS read the NIST Computer Security Resource Center document SP800-81 Rev.1, "Secure Domain Naming System (DNS) Guide" at: http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf It recommends rolling th KSK every 12 to 24 months and the ZSK every 1 to 3 months. These values are unchanged from the original SP800-81 issues back at least two years ago and probably three. Everyone I have spoken with who works with crypto feels that, barring a math breakthough, these numbers are VERY conservative. I might also mention that US government system are required to follow the recommendations of SP800-81r1. > 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. I can see no point in the use of lower bit size keys. Current systems are able to deal with the sizes now in use. Shortening keys simply weakens the system. I agree with your concern with long intervals between signing. Blowing a key roll is a really unpleasant things and will get more so as more and more servers start doing validation. > 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. Good advice! > 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. HSMs are the way to go...if you can afford them. Prices vary a LOT from expensive to WOW! (So does functionality, and DNSSEC will typically take very little.) Because of dynamic DNS requirements, keeping the private ZSK on-line is allowed, even for government sites, though ONLY in cases where dynamic DNS is used or the back-end DNS management system requires it. Government sites may not keep the KSK on-line. See SP800-81r1 Section 9.4 for details. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
