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

[Kalman Feher]

On 20/09/10 6:09 PM, "Kevin Oberman" <oberman at es.net> wrote:

>> 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.
That depends on what one assumes to be the base size. It also depends on
what one intends to use the keys for. The bulk of the advice within 800-81r1
assumes the target is a single or small number of production domains. The
operational recommendations would become unwieldy very fast at large scales.
The .GOV registry also has different policies around keys than other
registries. Key groups (or lack thereof) being an obvious difference, and
one that may impact how you feel about life times and bit sizes.

The other item of concern not directly addressed by 800-81r1 (since its
target audience wouldn't care that much), is the impact of signing many
(hundreds or thousands) domains. Bit sizes, life times, signing jitter and
overall domain size become of far more concern when your server will be
signing effectively all the time. Even allowing for dedicated signing
systems, you'll care a lot more about these issues.

Another report that may be more appropriate if you have a large number of
domains is the Shinkuro "Setting the parameters" report.
http://www.dnssec-deployment.org/documents/SettingtheParameters.pdf. It is
aimed at larger collections of domains and thus the advice is focused at
issues of load and signing capacity.

This isn't a matter of which report is better. Rather, "which recommendation
is applicable to my organisation?". The NIST suggestions (if you are not a
government body) are entirely reasonable if your domain count is low. As the
domain count enters triple digits, other advice and research may be more
appropriate.

> 
> 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.

-- 
Kal Feher | Melbourne IT | Malmö, Sweden | ph: +46 406 919185 | mob: +46 734
224407