Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 22/09/10 11:29 AM, "Matus UHLAR - fantomas" wrote: >>> 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. >imho it's perfect. Analogies to specific issues are a poor idea. They abstract details that should be considered and by trying to visualise the new example you associate properties that don't exist within the original problem. I could list differences but it would pander to the belief that somewhere out there is the perfect non DNS example to a DNS problem. Zone walking and its perceived risks should only be considered in light of DNS knowledge, not boats, not phone switchboards or any other non DNS item. Its fine to convey simple concepts using an analogy. But by using one for a specific issue (on bind-users), you betray ignorance of the problem at hand by relying on unrelated behaviours and properties to fill in the blanks for you. It is a poor analogy because so many of the properties of the original problem (DNS software, zone walking software, publically available RRs) simply do not behave in ways even vaguely similar to a human answering a phone. If you think zone walking prevention (such as it is) makes you more secure. I say prove it. Show me something measureable. Show me how you can protect a publically available resource by preventing zone walking (which isn't preventable by the way). After that, feel free to tell me how a phone switchboard would implement the same solution. -- 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?
> >> 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. imho it's perfect. > On 2010-09-21 16:56, Phil Mayers wrote: > > Do you have reverse DNS in .in-addr.arpa? On 22.09.10 11:24, Niobos wrote: > Yes > > 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. > A few seconds and how long will it take for /48 (2^80 = 1208925819614629174706176) in ipv6 environment? :) > > Attackers can gain a lot of info from this; > Correct at present, yes. with ipv6, they will rely much more on DNS or other public informations. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. ___ 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 16:56, Phil Mayers wrote: > On 21/09/10 14:43, Niobos wrote: >> On 2010-09-21 15:32, Kalman Feher wrote: >>> On 21/09/10 8:43 AM, "Niobos" 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? Yes > 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. A few seconds > Attackers can gain a lot of info from this; Correct > certainly not *all* forward > lookups, but a lot of them. My zone consists of mostly CNAMEs that map vhosts to physical hosts; you won't find these with .in-addr.arpa. Greetings, Niobos ___ 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 16:46, Kalman Feher wrote: > If you don't > want someone to know it, don't make it public (at the very least). I agree totally! > 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. I agree. But I'd argue that there are different "grades" of public information. My home phone number is public. You can look it up in the (paper or electronic) phonebook. That doesn't mean I'll put it in the footer of every mail/facebook/twitter I send out. Hell, I even use an alias to post to newsgroups instead of my real name. And sure you can figure out who I am, that info is publicly available somewhere (despite my efforts), but I'm not going to hand it to you on a plate. In that sense, I still believe that using NSEC3 over NSEC adds another barrier to those who want to walk your zone. And while it's possible (you could even argue "easy") to overcome, it's yet another speed bump. The whole point of NSEC3 was to make zone walking as difficult as brute-forcing the server, not to make it impossible. > Taking steps to > prevent that is likely to waste more of your time than it will of those > looking. Unless you're calculating the NSEC3 hashes by hand, it took me under 1 minute to add an NSEC3PARAM RRset to my zone. And I'm fairly confident that it will take at least 1 minute longer to walk an NSEC3 zone than an NSEC zone. Greets, Niobos ___ 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 22/09/10 4:14 AM, "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. Not surprising that you've missed the point given the long thread, but I'll reiterate here. The concern was that a zone could be walked even _with_ NSEC3. Use whichever NSEC floats your (leaky) boat. It isn't going to stop public information from falling into an evil persons hands. I'd recommend being a little more sensible and only making public that which you want to be public. Then protecting all systems addressed within the zone as if bad people knew about them, regardless of the "these are not the RRs you're looking for" magical powers of NSEC3. > > > Doug (... and it annoys the pig) -- 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 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
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 21/09/10 16:40, Lightner, Jeff wrote: I always liken arguments such as this to a leaky boat. While one certainly does more to eliminate the boat filling with water by plugging the big holes that does NOT mean there is no value is caulking the small ones. Over time enough of the small ones might be enough to swamp the boat. Well, to each his own. ___ 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?
I always liken arguments such as this to a leaky boat. While one certainly does more to eliminate the boat filling with water by plugging the big holes that does NOT mean there is no value is caulking the small ones. Over time enough of the small ones might be enough to swamp the boat. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Phil Mayers Sent: Tuesday, September 21, 2010 10:56 AM To: bind-users@lists.isc.org Subject: 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, "Niobos" 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 Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ 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, "Niobos" 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 21/09/10 3:43 PM, "Niobos" wrote: > On 2010-09-21 15:32, Kalman Feher wrote: >> On 21/09/10 8:43 AM, "Niobos" 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. 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. > >> 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 -- 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" 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 8:43 AM, "Niobos" 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?
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 20/09/10 6:09 PM, "Kevin Oberman" wrote: >> Date: Mon, 20 Sep 2010 11:03:31 +0200 >> From: Kalman Feher >> Sender: bind-users-bounces+oberman=es@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 genui
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
> Date: Mon, 20 Sep 2010 11:03:31 +0200 > From: Kalman Feher > Sender: bind-users-bounces+oberman=es@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. 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. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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?
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" 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@lists.isc.org > https://lists.isc.org/
NSEC3 salt lifetime (and some other DNSSEC params): sane value?
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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
