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

[Niobos]

Thank you for the excellent advice!

On 2010-09-20 18:09, Kevin Oberman wrote:
> 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.
Very interesting read.

However, for my original question, the NIST document says:
> If the zone is signed using NSEC3 RRs, the salt value should be changed
> every time the zone is completely resigned
Since my zone is only updated dynamically, I'll never *completely*
resign my zone... Also, they do mention that "[the salt] should be
changed on a regular basis to maintain protection against zone enumeration."
However, I don't see how it protects the zone from that if I use Daniel
Bernstein's method (i.e. guess a name & hash it. If it's outside a known
hash-range, request the server. Either it's a hit, or it's a new
hash-range.) If the hash changes halfway through the procedure, I just
rehash all my hits and go on. This is hardly a slowdown at all.


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

It's a private zone; HSM's are waaaaaay too expensive for that purpose!
I use DDNS daily, so that requires the ZSK to be online. The KSK can
remain offline if I manually resign the new DNSKEY RRset every Lzsk
(i.e. every month). I'm not sure I'll have the courage to do this...