Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
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 waay 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... ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 21/09/10 8:43 AM, Niobos nio...@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 waay 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 2010-09-21 15:32, Kalman Feher wrote: On 21/09/10 8:43 AM, Niobos nio...@dest-unreach.be wrote: 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. I'll reply with a quote from the BIND DNS book: It’s the difference between letting random folks call your company’s switchboard and ask for John Q. Cubicle’s phone number [versus] sending them a copy of your corporate phone directory. On a large scale, manual intervention would make me very concerned with the likelihood of human based outages. I'm even concerned that this will be the problem on my private zone... thank you again for the very insightful info! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 21/09/10 14:43, Niobos wrote: On 2010-09-21 15:32, Kalman Feher wrote: On 21/09/10 8:43 AM, Niobosnio...@dest-unreach.be wrote: 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. I'll reply with a quote from the BIND DNS book: It’s the difference between letting random folks call your company’s switchboard and ask for John Q. Cubicle’s phone number [versus] sending them a copy of your corporate phone directory. That is a poor analogy. Do you have reverse DNS in .in-addr.arpa? Have you timed how long an nmap -sL yoursubnet/mask takes? Because it doesn't take very long for us, and we've got a lot of large subnets. Attackers can gain a lot of info from this; certainly not *all* forward lookups, but a lot of them. Pretending that stopping zone enumeration is much of a security boost is just that IMHO - pretending. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 9/21/2010 7:46 AM, Kalman Feher wrote: It may well be analogous to that (though I disagree), but the quote does not substantiate why knowing public information is bad. In the example above, you've simply saved your switchboard and the caller some time. If you don't want someone to know it, don't make it public (at the very least). You'll have to accept that no matter what steps you take, your public information will be available to those who wish to find it. Taking steps to prevent that is likely to waste more of your time than it will of those looking. When this topic first came up 12+ years ago I (and others) said that DNSSEC would never see wide deployment unless the ability to walk the zone was eliminated. We were all poo-pooed at the time with lots of security through obscurity, LOL type arguments. Development of DNSSEC specs continued to ignore the need to eliminate zone-walking for almost a decade until finally a consortium of folks more influential than I put their foot down and hammered out the NSEC3 spec (abridging the history here for the sake of a good story). My point being, it really doesn't matter if you agree with the reasoning or not, whether you understand the use case(s) or not, or whether you ever deploy NSEC3 or not. The fact is that there are a non-trivial number of organizations who will not deploy DNSSEC without it, so attempting to convince people not to use it is pointless. Doug (... and it annoys the pig) -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On Sep 21, 2010, at 10:14 PM, Doug Barton wrote: On 9/21/2010 7:46 AM, Kalman Feher wrote: It may well be analogous to that (though I disagree), but the quote does not substantiate why knowing public information is bad. In the example above, you've simply saved your switchboard and the caller some time. If you don't want someone to know it, don't make it public (at the very least). You'll have to accept that no matter what steps you take, your public information will be available to those who wish to find it. Taking steps to prevent that is likely to waste more of your time than it will of those looking. When this topic first came up 12+ years ago I (and others) said that DNSSEC would never see wide deployment unless the ability to walk the zone was eliminated. We were all poo-pooed at the time with lots of security through obscurity, LOL type arguments. Development of DNSSEC specs continued to ignore the need to eliminate zone-walking for almost a decade until finally a consortium of folks more influential than I put their foot down and hammered out the NSEC3 spec (abridging the history here for the sake of a good story). My point being, it really doesn't matter if you agree with the reasoning or not, whether you understand the use case(s) or not, or whether you ever deploy NSEC3 or not. The fact is that there are a non-trivial number of organizations who will not deploy DNSSEC without it, so attempting to convince people not to use it is pointless. This is *very* true, and (IMO) something that I think it would be very useful for the v6 community to fully grok -- it matters not how awesome your solution is, if it doesn't do what the customer wants, they just won't deploy it (see the DHCPv6 discussions, etc)... W Doug (... and it annoys the pig) -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
