NSEC3 salt lifetime (and some other DNSSEC params): sane value?

[Kevin Oberman]

> Date: Mon, 20 Sep 2010 11:03:31 +0200
> From: Kalman Feher <kalman.feher at melbourneit.com.au>
> Sender: bind-users-bounces+oberman=es.net at 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: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751