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

Kalman Feher kalman.feher at melbourneit.com.au
Mon Sep 20 09:03:31 UTC 2010


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" <niobos at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 




More information about the bind-users mailing list