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

[Kalman Feher]

On 21/09/10 8:43 AM, "Niobos" <niobos at dest-unreach.be> wrote:

> 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...
During ZSK roll over.
> Also, they do mention that "[the salt] should be
> changed on a regular basis to maintain protection against zone enumeration."
I personally find protection against zone enumeration to be a false sense of
security. If it's public people will find it. Ask your self what it is that
you want publically accessible yet you don't want others to be aware of.


> 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...
A small scale offline key management process may be something like:

1. install key creation tools on dedicated laptop or other non permanently
connected host. (bind dnssec tools or opendnssec or tools of your choice)
2. script up the creation including lifetimes.
3. script up a transfer from the offline node to master server. Place keys
in "key-directory" on master server.
4. master server rolls over based on lifetime values (assuming BIND 9.7+)
5. remove ksk
6. rinse and repeat next month

Security depends on how well you protect your key-generating system, on
whether your master server is a hidden master or publically accessible (for
any service) and how tightly you script the process. On a small scale, this
should certainly provide acceptable security. On a large scale, manual
intervention would make me very concerned with the likelihood of human based
outages. 

> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher