Re: US government mandates? use of DNSSEC by federal agencies
On Wed, Aug 27, 2008 at 09:22:40AM -0700, Michael Thomas wrote: Kevin Oberman wrote: Date: Tue, 26 Aug 2008 16:53:24 -0400 From: Bill Bogstad [EMAIL PROTECTED] Not sure what this will actually mean in the long run, but it's at least worth noting. http://www.gcn.com/online/vol1_no1/46987-1.html http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf It will mean something in the medium term as '.gov' and '.org' will be signed very soon and OMB might be able to even get the root signed. (Since OMB can pull funding, no one argues with them much.) All of this will increase pressure on Verisign to deal with '.com' and '.net'. Note that this only has an impact on '.gov' and the zones immediately below it, but I suspect most sub-domains of *.gov will be signed as a result of this, even if it is not required. So the question I have is... will operators (ISP, etc) turn on DNSsec checking? Or a more basic question of whether you even _could_ turn on checking if you were so inclined? I know that we made sure it was turned on as part of our patch process for our customer facing resolvers. IIRC the default may have changed in bind as well if you actually read the changelog. 2405. [cleanup] The default value for dnssec-validation was changed to yes in 9.5.0-P1 and all subsequent releases; this was inadvertently omitted from CHANGES at the time. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: US government mandates? use of DNSSEC by federal agencies
Date: Wed, 27 Aug 2008 09:22:40 -0700 From: Michael Thomas [EMAIL PROTECTED] Kevin Oberman wrote: Date: Tue, 26 Aug 2008 16:53:24 -0400 From: Bill Bogstad [EMAIL PROTECTED] Not sure what this will actually mean in the long run, but it's at least worth noting. http://www.gcn.com/online/vol1_no1/46987-1.html http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf It will mean something in the medium term as '.gov' and '.org' will be signed very soon and OMB might be able to even get the root signed. (Since OMB can pull funding, no one argues with them much.) All of this will increase pressure on Verisign to deal with '.com' and '.net'. Note that this only has an impact on '.gov' and the zones immediately below it, but I suspect most sub-domains of *.gov will be signed as a result of this, even if it is not required. So the question I have is... will operators (ISP, etc) turn on DNSsec checking? Or a more basic question of whether you even _could_ turn on checking if you were so inclined? As far as I can see, at least with bind-9.5, operators would have to turn it off. It looks to me like dnssec-validation defaults to on. It also appears that bind-9.4 defaults to 'off'. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpaoRvrXRBfz.pgp Description: PGP signature
Re: US government mandates? use of DNSSEC by federal agencies
On Wed, 27 Aug 2008 09:53:26 -0700 Kevin Oberman [EMAIL PROTECTED] wrote: So the question I have is... will operators (ISP, etc) turn on DNSsec checking? Or a more basic question of whether you even _could_ turn on checking if you were so inclined? As far as I can see, at least with bind-9.5, operators would have to turn it off. It looks to me like dnssec-validation defaults to on. It also appears that bind-9.4 defaults to 'off'. Right. The real questions are the clients and the trust anchor -- what root key do you support? --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: US government mandates? use of DNSSEC by federal agencies
In a message written on Wed, Aug 27, 2008 at 10:14:48AM -0700, David Conrad wrote: Note that if you do turn on DNSSEC, you're going to have to make sure the trust anchors you configure get updated. Trust anchors have a validity period and if they're not updated before they expire validation will fail (which will appear to users of the resolver pretty much like a DNS failure for all the names in the signed zone). Be careful out there. While signing the root is the best solution, an alternate solution until that happens is DLV, as documented in RFC 4431. You can run your own setup, or trust someone to do it for you. Note that ISC runs a DLV registry, if you wanted to trust them: https://secure.isc.org/index.pl?/ops/dlv/ -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpL8cEN8bsLy.pgp Description: PGP signature
Re: US government mandates? use of DNSSEC by federal agencies
Steven M. Bellovin wrote: On Wed, 27 Aug 2008 09:53:26 -0700 Kevin Oberman [EMAIL PROTECTED] wrote: So the question I have is... will operators (ISP, etc) turn on DNSsec checking? Or a more basic question of whether you even _could_ turn on checking if you were so inclined? As far as I can see, at least with bind-9.5, operators would have to turn it off. It looks to me like dnssec-validation defaults to on. It also appears that bind-9.4 defaults to 'off'. Right. The real questions are the clients and the trust anchor -- what root key do you support? A distributed one. I personally don't really see an issue with downloading a public key for every TLD out there. These keys could come in a pack even by an OS distribution, nicely PGP signed et all... Nobody in his right mind manages this per box anymore anyway, and packages for distributions and auto-updates are well-present anyway. The presence of a key file can also mean to the resolver that one can/has_to check dnssec results. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: US government mandates? use of DNSSEC by federal agencies
Date: Wed, 27 Aug 2008 19:25:03 +0200 From: Jeroen Massar [EMAIL PROTECTED] Steven M. Bellovin wrote: On Wed, 27 Aug 2008 09:53:26 -0700 Kevin Oberman [EMAIL PROTECTED] wrote: So the question I have is... will operators (ISP, etc) turn on DNSsec checking? Or a more basic question of whether you even _could_ turn on checking if you were so inclined? As far as I can see, at least with bind-9.5, operators would have to turn it off. It looks to me like dnssec-validation defaults to on. It also appears that bind-9.4 defaults to 'off'. Right. The real questions are the clients and the trust anchor -- what root key do you support? A distributed one. I personally don't really see an issue with downloading a public key for every TLD out there. These keys could come in a pack even by an OS distribution, nicely PGP signed et all... Nobody in his right mind manages this per box anymore anyway, and packages for distributions and auto-updates are well-present anyway. The presence of a key file can also mean to the resolver that one can/has_to check dnssec results. How do you propose to establish the initial trust for these keys? How will they be updated? NIST recommends rolling the zone keys every month and the key signing key annually. Files in distributions are way too static for these intervals. (I think NIST's recommendations are extremely excessive, but I am required to comply with them or explain to OMB why not.) This is the reason for the DLV concept and it will be needed (in some form) at least until the root is signed and most likely until .com and .net are signed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp9JRYHP0K6S.pgp Description: PGP signature
Re: US government mandates? use of DNSSEC by federal agencies
Kevin Oberman wrote: [..] Right. The real questions are the clients and the trust anchor -- what root key do you support? A distributed one. I personally don't really see an issue with downloading a public key for every TLD out there. These keys could come in a pack even by an OS distribution, nicely PGP signed et all... Nobody in his right mind manages this per box anymore anyway, and packages for distributions and auto-updates are well-present anyway. The presence of a key file can also mean to the resolver that one can/has_to check dnssec results. How do you propose to establish the initial trust for these keys? One already trusts the distribution, taking Debian as an example, all packages are signed by their key. I am already trusting them that they don't install backdoors on my boxes (or make weak keys :) by installing packages I install from their servers. Thus having them provide me with those keys is simple for them, just package them up (which mean they sign it), and let bind/resolver depend on that package. This would even upgrade boxes which don't have the package yet, eg similar to the ssh-vulnkey package which is now on all updated Debian and Ubuntu boxes worldwide. This takes care of all the distribution work, all the infrastructure is there already. Same for Fedora/SUSE/Windows etc etc. You will need to get the vendor to support this thing though, but if the vendor doesn't do it, you won't either have a resolver which supports it, unless you start doing custom installs. Note that one can already easily make a package and put it in a local repository which does exactly this. Which could allow one to have local packages with keys for other domains, thus avoiding problems when a higher key breaks, avoiding any disaster down the line. How will they be updated? NIST recommends rolling the zone keys every month and the key signing key annually. Files in distributions are way too static for these intervals. (I think NIST's recommendations are extremely excessive, but I am required to comply with them or explain to OMB why not.) Never heard of apt-get update? :) People who don't upgrade their boxes (even only the security updates, which this would fall under) don't deserve to be on the Internet IMHO anyway. I am pretty sure that for these kind of 'force-upgrades' which, if not upgraded, would definitely break things, that there can be a mechanism (which can be turned of) that auto-updates the package without intervention. As for the interval, a month is not too bad for this, one should do security upgrades the day they come out. There is one problem though, and that is that keys should be 'overlapping', thus that there is no hole where no single key is valid, give it at least a week or two for everybody to upgrade. This is the reason for the DLV concept and it will be needed (in some form) at least until the root is signed and most likely until .com and .net are signed. Having per-TLD keys distributed in this way would not even require that. DLV's are a good thing though if they are not there yet, but you still need to install a config snippet, having distributions do that would save a lot of overhead/reinvention. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: US government mandates? use of DNSSEC by federal agencies
Jeroen Massar wrote: Steven M. Bellovin wrote: On Wed, 27 Aug 2008 09:53:26 -0700 Kevin Oberman [EMAIL PROTECTED] wrote: So the question I have is... will operators (ISP, etc) turn on DNSsec checking? Or a more basic question of whether you even _could_ turn on checking if you were so inclined? As far as I can see, at least with bind-9.5, operators would have to turn it off. It looks to me like dnssec-validation defaults to on. It also appears that bind-9.4 defaults to 'off'. Right. The real questions are the clients and the trust anchor -- what root key do you support? A distributed one. I personally don't really see an issue with downloading a public key for every TLD out there. These keys could come in a pack even by an OS distribution, nicely PGP signed et all... Nobody in his right mind manages this per box anymore anyway, and packages for distributions and auto-updates are well-present anyway. The presence of a key file can also mean to the resolver that one can/has_to check dnssec results. Heh, maybe you could manage root key update like any other security alert/update on your host OS... Of course embedded frobs that don't auto-update like, oh say, your favorite router could be problematic. And I'd assume that those key parts of the infrastructure are probably not too keen on trusting their upstream resolver to do the checking for them. In any case, the point of my first question was really about the concern of false positives. Do we really have any idea what will happen if you hard fail dnssec failures? If I were running a large site, I'd want to monitor the failures for a while. If nothing else, dnssec is a complicated beast and bakeoffs can only flush so many bugs out. Mike
Re: US government mandates? use of DNSSEC by federal agencies
On Aug 27, 2008, at 10:25 AM, Jeroen Massar wrote: Right. The real questions are the clients and the trust anchor -- what root key do you support? A distributed one. I personally don't really see an issue with downloading a public key for every TLD out there. These keys could come in a pack even by an OS distribution, nicely PGP signed et all... https://par.icann.org/files/paris/IANAReportKim_24Jun08.pdf, slides 3 through 11. Regards, -drc
Re: US government mandates? use of DNSSEC by federal agencies
Just speaking of the IANA ITAR... On Aug 27, 2008, at 10:35 AM, Kevin Oberman wrote: How do you propose to establish the initial trust for these keys? Current plan: - The IANA ITAR will be reachable via HTTPS, so you could trust the CA IANA uses for that website (don't know who that is offhand). - The IANA ITAR will be PGP signed, so you could trust the IANA PGP key you obtained via some out of band mechanism. The data used in the IANA ITAR will be vetted the same way IANA vets NS changes. How will they be updated? Not sure I understand this question. If you mean how frequently will the trust anchors within the IANA ITAR be updated, that's up to the TLD admins. If you mean how will the set of trust anchors be updated, I would imagine folks would have a cron job to pull down the trust anchors periodically or something. The data is relatively static and could be Akamaized (or equivalent) or something if load becomes a problem (not something I'd personally be expecting in the foreseeable future). This is the reason for the DLV concept and it will be needed (in some form) at least until the root is signed and most likely until .com and .net are signed. The downside of DLV is that it puts the DLV registry into the name resolution path, with all that implies in terms of data privacy as well as reliability. Regards, -drc
Re: US government mandates? use of DNSSEC by federal agencies
On Aug 27, 2008, at 11:03 AM, Michael Thomas wrote: Of course embedded frobs that don't auto-update like, oh say, your favorite router could be problematic. You have a router that supports DNSSEC that can't be made to do some form of auto-update? In any case, the point of my first question was really about the concern of false positives. Do we really have any idea what will happen if you hard fail dnssec failures? As far as I'm aware, there is no 'soft fail' for DNSSEC failures. In the caching servers I'm familiar with, if a name fails to validate, it used to be that it doesn't get cached and SERVFAIL is returned. Maybe that's been fixed? Regards, -drc
Re: US government mandates? use of DNSSEC by federal agencies
David Conrad wrote: On Aug 27, 2008, at 11:03 AM, Michael Thomas wrote: In any case, the point of my first question was really about the concern of false positives. Do we really have any idea what will happen if you hard fail dnssec failures? As far as I'm aware, there is no 'soft fail' for DNSSEC failures. In the caching servers I'm familiar with, if a name fails to validate, it used to be that it doesn't get cached and SERVFAIL is returned. Maybe that's been fixed? Sure, but my point is that if DNSsec all of a sudden has some relevance which is not the case today, any false positives are going to come into pretty stark relief. As in, .gov could quite possibly setting themselves up for self-inflicted denial of service given buginess in the signers, the verifiers or both. Given how integral DNS is to everything, it seems a little scary to just trust that all of that software across many, many vendors is going to interoperate at *scale*. It seems that some training wheels like an accept-failure-but-log mode with feedback like your domain failed to the domain's admins might be safer. At least for a while, as this new treadmill's operational care and feeding is established. Mike
Re: US government mandates? use of DNSSEC by federal agencies
Michael, On Aug 27, 2008, at 5:15 PM, Michael Thomas wrote: Sure, but my point is that if DNSsec all of a sudden has some relevance which is not the case today, any false positives are going to come into pretty stark relief. Yep. As in, .gov could quite possibly setting themselves up for self-inflicted denial of service given buginess in the signers, the verifiers or both. Given how long the signers and verifiers have been around, I suspect a more likely failure mode is folks running caching servers forgetting to update trust anchors and/or signers forgetting to resign before the validity period expires. However, bugs do happen... Given how integral DNS is to everything, it seems a little scary to just trust that all of that software across many, many vendors is going to interoperate at *scale*. It seems that some training wheels like an accept-failure-but-log mode with feedback like your domain failed to the domain's admins might be safer. At least for a while, as this new treadmill's operational care and feeding is established. I agree and I know for certain this has been suggested in the past for at least one of the validating caching servers. However, I gather this hasn't been implemented Regards, -drc
Re: US government mandates? use of DNSSEC by federal agencies
Date: Tue, 26 Aug 2008 16:53:24 -0400 From: Bill Bogstad [EMAIL PROTECTED] Not sure what this will actually mean in the long run, but it's at least worth noting. http://www.gcn.com/online/vol1_no1/46987-1.html http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf It will mean something in the medium term as '.gov' and '.org' will be signed very soon and OMB might be able to even get the root signed. (Since OMB can pull funding, no one argues with them much.) All of this will increase pressure on Verisign to deal with '.com' and '.net'. Note that this only has an impact on '.gov' and the zones immediately below it, but I suspect most sub-domains of *.gov will be signed as a result of this, even if it is not required. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpCIOrtUhcgp.pgp Description: PGP signature
