US government mandates? use of DNSSEC by federal agencies
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 Bill Bogstad
Date: Tue, 26 Aug 2008 16:53:24 -0400 From: "Bill Bogstad" <bogstad@pobox.com>
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: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Kevin Oberman wrote:
Date: Tue, 26 Aug 2008 16:53:24 -0400 From: "Bill Bogstad" <bogstad@pobox.com>
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? Mike
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" <bogstad@pobox.com>
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 jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Aug 27, 2008, at 9:33 AM, Jared Mauch wrote:
So the question I have is... will operators (ISP, etc) turn on DNSsec checking?
Some ISPs already do (I believe Telia-Sonera in SE in one).
Or a more basic question of whether you even _could_ turn on checking if you were so inclined?
You can turn on DNSSEC if you are running BIND 9, Unbound, or Nominum CNS as a caching server. If you are running DJB's dnscache, PowerDNS, or using OpenDNS's service, you don't have the option. If you're running BIND 8 or BIND 4, kill yourself now.
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.
In BIND, there appear to be 3 things that have to be configured for DNSSEC to do anything useful: options { dnssec-enable yes; dnssec-validation yes; }; and trusted-keys { <the trust anchors for zones you want to validate>; }; If all of these aren't set correctly, DNSSEC might as well be off. I'm told, however, that BIND (since version 9.1) and Unbound default to always sending the "DNSSEC OK" bit on so if the zone you're talking to is signed, DNSSEC cruft will be returned regardless of whether your caching server is configured to do anything with it. In some future and/or alternate universe, all you'll need is a single trust anchor for the root after it gets signed. Until that time, you have to list the trust anchors for all the zones you want to validate. Right now, there are 4 signed TLDs (SE, BR, PR, BG) and the RIPE in-addr.arpa/ip6.arpa trees are signed. There are also a few other scattered zones that are signed, see http:// secspider.cs.ucla.edu/ for a list. 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." Regards, -drc
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 - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Date: Wed, 27 Aug 2008 09:22:40 -0700 From: Michael Thomas <mike@mtcc.com>
Kevin Oberman wrote:
Date: Tue, 26 Aug 2008 16:53:24 -0400 From: "Bill Bogstad" <bogstad@pobox.com>
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: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Wed, 27 Aug 2008 09:53:26 -0700 "Kevin Oberman" <oberman@es.net> 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
Steven M. Bellovin wrote:
On Wed, 27 Aug 2008 09:53:26 -0700 "Kevin Oberman" <oberman@es.net> 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
Date: Wed, 27 Aug 2008 19:25:03 +0200 From: Jeroen Massar <jeroen@unfix.org>
Steven M. Bellovin wrote:
On Wed, 27 Aug 2008 09:53:26 -0700 "Kevin Oberman" <oberman@es.net> 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: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
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
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
Jeroen Massar wrote:
Steven M. Bellovin wrote:
On Wed, 27 Aug 2008 09:53:26 -0700 "Kevin Oberman" <oberman@es.net> 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
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
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
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
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
participants (8)
-
Bill Bogstad -
David Conrad -
Jared Mauch -
Jeroen Massar -
Kevin Oberman -
Leo Bicknell -
Michael Thomas -
Steven M. Bellovin