Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Jim Gettys wrote: > Radio clock receivers often don't work where these devices are deployed > (like in my basement). Not enough view of the sky (and multiple layers of > floors). Radios are "nice to have", but can't be guaranteed to work. No, the problem of radio clock is not its availability but that they can easily be faked, which means it is no better than relying on some NTP service, such as time.nist.gov, which is as (un)trustworthy as USG. Masataka Ohta
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Fri, Sep 13, 2013 at 5:33 PM, Glen Wiley wrote: > This discussion highlights the importance of making sure that hardware > vendors understand the need for working clocks that can be easily > bootstrapped. In addition to NTP radio clock receivers are ubiquitous, > tiny and ridiculously cheap. It is unconscionable that any consumer > electronics are sold today that boast a visible clock without including a > radio clock receiver! This doesn't fix the mountain of already deployed > SOHO gear, but it is time for vendors that know better (Cisco, Netgear, > D-Link, etc.) to do the right thing. > Radio clock receivers often don't work where these devices are deployed (like in my basement). Not enough view of the sky (and multiple layers of floors). Radios are "nice to have", but can't be guaranteed to work. > > I put entropy in a similar class of problem as radio clock receivers. > There are a number of reasonable sources for entropy that take up > virtually no PCB space and can be built with a few discrete components > (thinking of quantum effects between 2 transistor gates or zener breakdown > noise on a zener diode). Stronger entropy sources get expensive - but > something that provides reasonable entropy for light crypto should be > available on SOHO class network gear. > Yes, and probably will be someday, and we should all encourage them to do so. I agree that SOC vendors should be encouraged to include such generators (as but one of many sources of entropy: see the following discussion: https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J ). Doesn't help in the meanwhile - Jim > On Sep 12, 2013, at 2:19 PM, robert bownes wrote: > > > Chiming in a bit late here, however, the availability of stratum 1 clocks > and stratum 2 class time data on non IP and/or non interconnected networks > is now so large, I question why one would run NTP outside of the building > in many cases, certainly in an enterprise of any size. > > A 1pulse per second aligned to GPS is good to a few ns. Fairly > straightforward to plug into even a OpenWrt type of router. Turn on the pps > in NTP on the router and you are good to go. > > > > > > On Tue, Sep 10, 2013 at 6:45 PM, Evan Hunt wrote: > >> On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote: >> > My colleagues and I worked on OpenWrt routers to get Unbound to work >> > there, what you need to do is to start DNS up in non-validating mode >> wait >> > for NTP to fix time, then check if the link allows DNSSEC answers >> > through, at which point you can enable DNSSEC validation. >> >> That's roughly what we did with BIND on OpenWrt/CeroWrt as well. We >> also discussed hacking NTP to set the CD bit on its initial DNS queries, >> but I don't think any of the code made it upstream. >> >> My real recommendation would be to run an NTP pool in an anycast cloud of >> well-known v4 and v6 addresses guaranteed to be reliable over a period of >> years. NTP could then fall back to those addresses if unable to look up >> the >> server it was configured to use. DNS relies on a well-known set of root >> server addresses for bootstrapping; I don't see why NTP shouldn't do the >> same. >> >> (Actually... the root nameservers could *almost* provide a workable time >> tick for bootstrapping purposes right now: the SOA record for the root >> zone encodes today's date in the serial number. So you do the SOA lookup, >> set your system clock, attempt validation; on failure, set the clock an >> hour forward and try again; on success, use NTP to fine-tune. Klugey! :) ) >> >> -- >> Evan Hunt -- e...@isc.org >> Internet Systems Consortium, Inc. >> ___ >> DNSOP mailing list >> dn...@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > ___ > DNSOP mailing list > dn...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > >
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
This discussion highlights the importance of making sure that hardware vendors understand the need for working clocks that can be easily bootstrapped. In addition to NTP radio clock receivers are ubiquitous, tiny and ridiculously cheap. It is unconscionable that any consumer electronics are sold today that boast a visible clock without including a radio clock receiver! This doesn't fix the mountain of already deployed SOHO gear, but it is time for vendors that know better (Cisco, Netgear, D-Link, etc.) to do the right thing. I put entropy in a similar class of problem as radio clock receivers. There are a number of reasonable sources for entropy that take up virtually no PCB space and can be built with a few discrete components (thinking of quantum effects between 2 transistor gates or zener breakdown noise on a zener diode). Stronger entropy sources get expensive - but something that provides reasonable entropy for light crypto should be available on SOHO class network gear. On Sep 12, 2013, at 2:19 PM, robert bownes wrote: > > Chiming in a bit late here, however, the availability of stratum 1 clocks and > stratum 2 class time data on non IP and/or non interconnected networks is now > so large, I question why one would run NTP outside of the building in many > cases, certainly in an enterprise of any size. > > A 1pulse per second aligned to GPS is good to a few ns. Fairly > straightforward to plug into even a OpenWrt type of router. Turn on the pps > in NTP on the router and you are good to go. > > > > > > On Tue, Sep 10, 2013 at 6:45 PM, Evan Hunt wrote: > On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote: > > My colleagues and I worked on OpenWrt routers to get Unbound to work > > there, what you need to do is to start DNS up in non-validating mode wait > > for NTP to fix time, then check if the link allows DNSSEC answers > > through, at which point you can enable DNSSEC validation. > > That's roughly what we did with BIND on OpenWrt/CeroWrt as well. We > also discussed hacking NTP to set the CD bit on its initial DNS queries, > but I don't think any of the code made it upstream. > > My real recommendation would be to run an NTP pool in an anycast cloud of > well-known v4 and v6 addresses guaranteed to be reliable over a period of > years. NTP could then fall back to those addresses if unable to look up the > server it was configured to use. DNS relies on a well-known set of root > server addresses for bootstrapping; I don't see why NTP shouldn't do the > same. > > (Actually... the root nameservers could *almost* provide a workable time > tick for bootstrapping purposes right now: the SOA record for the root > zone encodes today's date in the serial number. So you do the SOA lookup, > set your system clock, attempt validation; on failure, set the clock an > hour forward and try again; on success, use NTP to fine-tune. Klugey! :) ) > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > ___ > DNSOP mailing list > dn...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > dn...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Martin Rex wrote: > There is no problem with the assumption that trusted third party > _could_ exist. It couldn't. What organization in US can be trusted against attacks by USG? Note that Snowden demonstrated that even USG failed to keep its top secret. > The reason where PKI breaks badly is whenever the third party that > Bob selected as _his_ third party is not a third party that Alice > has volutarily chosen herself to trust. Instead, PKI forces > Alice to trust dozens of third parties, one or more per every > Bob out there. In short, PKI is against the end to end principle, because CAs are intelligent intermediate systems. But, if CAs were trusted third parties, it means both Alice and Bob can safely trust them. Masataka Ohta
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Dickson, Brian wrote: > In order to subvert or redirect a delegation, the TLD operator (or > registrar) would need to change the DNS server name/IP, and replace the DS > record(s). Only to a victim to be deceived. > This would be immediately evident to the domain owner, when they query the > TLD authority (delegation) servers. Wrong. The domain owners can't know some victims are supplied faked data. Masataka Ohta
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
robert bownes wrote: > A 1pulse per second aligned to GPS is good to a few ns. GPS time may be accurate, if it were assured to be secure. Masataka Ohta
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Masataka Ohta wrote: > > > It is still a hierarchical model of trust. So at the top, if you > > don't trust Verisign for the .COM domain and PIR for the .ORG domain > > (and for people who are worried about the NSA, both of these are US > > corporations), the whole system falls apart. > > Right. PKI is fundamentally broken, because its fundamental > assumption that trusted third parties could exist is a total > fallacy. I believe the problem is slightly different. There is no problem with the assumption that trusted third party _could_ exist. The reason where PKI breaks badly is whenever the third party that Bob selected as _his_ third party is not a third party that Alice has volutarily chosen herself to trust. Instead, PKI forces Alice to trust dozens of third parties, one or more per every Bob out there. -Martin
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Chiming in a bit late here, however, the availability of stratum 1 clocks and stratum 2 class time data on non IP and/or non interconnected networks is now so large, I question why one would run NTP outside of the building in many cases, certainly in an enterprise of any size. A 1pulse per second aligned to GPS is good to a few ns. Fairly straightforward to plug into even a OpenWrt type of router. Turn on the pps in NTP on the router and you are good to go. On Tue, Sep 10, 2013 at 6:45 PM, Evan Hunt wrote: > On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote: > > My colleagues and I worked on OpenWrt routers to get Unbound to work > > there, what you need to do is to start DNS up in non-validating mode wait > > for NTP to fix time, then check if the link allows DNSSEC answers > > through, at which point you can enable DNSSEC validation. > > That's roughly what we did with BIND on OpenWrt/CeroWrt as well. We > also discussed hacking NTP to set the CD bit on its initial DNS queries, > but I don't think any of the code made it upstream. > > My real recommendation would be to run an NTP pool in an anycast cloud of > well-known v4 and v6 addresses guaranteed to be reliable over a period of > years. NTP could then fall back to those addresses if unable to look up the > server it was configured to use. DNS relies on a well-known set of root > server addresses for bootstrapping; I don't see why NTP shouldn't do the > same. > > (Actually... the root nameservers could *almost* provide a workable time > tick for bootstrapping purposes right now: the SOA record for the root > zone encodes today's date in the serial number. So you do the SOA lookup, > set your system clock, attempt validation; on failure, set the clock an > hour forward and try again; on success, use NTP to fine-tune. Klugey! :) ) > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > ___ > DNSOP mailing list > dn...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 12, 2013, at 7:24 AM, Theodore Ts'o wrote:
> It is still a hierarchical model of trust. So at the top, if you
> don't trust Verisign for the .COM domain and PIR for the .ORG domain
> (and for people who are worried about the NSA, both of these are US
> corporations), the whole system falls apart.
Its also a constrained path of trust, and you can actually chose who you trust.
E.g. your application could be constructed to look up both
"{data}.dnssec-info-domain.com" and "{data}.dnssec-info-domain.ru". Only if
both use the same validated key is the key accepted.
That way, the trust becomes:
1: The root is trusted
2: The registrar for .com and .ru don't collaborate, since they must
collaborate for the trust to affect the results.
This is a huge difference from SSL, which unless you pin your application to
trust only a single CA, you end up having to trust the entire universe of
certificate authorities.
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edufull of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On 9/12/13 7:24 AM, "Theodore Ts'o" wrote: >On Wed, Sep 11, 2013 at 03:38:21PM -0400, Phillip Hallam-Baker wrote: >> > I disagree. DNSSEC is not just DNS: its the only available, >>deployed, and >> > (mostly) accessible global PKI currently in existence which also >>includes a >> > constrained path of trust which follows already established business >> > relationships. >> >> Except that virtually nobody uses DNSSEC and most of the registrars >>don't >> support it. > >More importantly, what problem do people think DNSSEC is going to >solve? > >It is still a hierarchical model of trust. So at the top, if you >don't trust Verisign for the .COM domain and PIR for the .ORG domain >(and for people who are worried about the NSA, both of these are US >corporations), the whole system falls apart. > >And even if you believe Verisign and PIR are a paragons of virtue >which are incorruptible (even when in a dark room when no one can see, >as the old Chinese saying goes), what about all of the registrars? There are vastly different aspects to trust in PKI vs DNSSEC, specifically about trust vs validation. In this context, "validation" means, having the domain owner verify that the DNSSEC and DNS records for their domain, reflect reality. In order to subvert or redirect a delegation, the TLD operator (or registrar) would need to change the DNS server name/IP, and replace the DS record(s). This would be immediately evident to the domain owner, when they query the TLD authority (delegation) servers. In other words, "trust but verify" is an intrinsic part of DNSSEC, regardless of where in the (trusted) hierarchy delegation occurs, or which parties are involved in updating the delegation components. DNS can't scale without delegation and caching. With DNSSEC, all of these elements support scalable, secure verification and validation. The ability to monitor this in real time, at centralized locations (TLD authority servers) scales very well and comes as close to a guarantee of verifiable security as is practical. On the other hand, a domain owner currently has no feasible way to determine that a PKI certificate has been issued for its domain (or any host in its domain), by any CA other than the CA that issued the "real" certificate. PKI certificates are tied to names, not IP addresses, and are not published anywhere. Thus, there is no method, short of querying every web server, BY NAME, via HTTPS, on the planet, to actively detect "forged" certificates. If DNSSEC is not used to protect the domain, having a forged certificate and poisoning DNS caches is all an attacker needs to do - or being a MitM, which removes the need to poison the cache. Brian
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On 9/12/13 2:07 PM, "Ted Lemon" wrote: >On Sep 12, 2013, at 1:49 PM, "Dickson, Brian" >wrote: >> In order to subvert or redirect a delegation, the TLD operator (or >> registrar) would need to change the DNS server name/IP, and replace the >>DS >> record(s). > >Someone who possesses the root key could in principle create a fake DNS >hierarchy with relatively few strategic changes, and present it only to >certain attack targets. This would be expensive, but not impossible. >It would not work, for example, for dragnet-style surveillance. I presume the "This", in respect to "expensive, but not impossible", refers to the creating the fake hierarchy. And that it does not refer to "possesses", as in acquiring the root key. (Pedantic probability math follows.) Excluding the direct methods of acquisition, let us consider the level of effort involved in recreating the root key, by brute force. We are looking at the average time to find a prime factor of a two-prime composite number of length 2048 bits, which places it in roughly the 1024 bit range. === First, for convenience, I'll give you all the time from the Big Bang until today, rather than the 5 year KSK key-roll window. (That's roughly 2^88 seconds.) Next, I'll also give you a factor of 2^100 for improvements in crypto key cracking vs prime sieve. And I'll also give you low-power CPUs at current high-clock-rates. 1 Watt per core, 2^32 instructions/second. And I'll also give you 1 guess per clock cycle. And we'll go with an average prime density of 1/10 (1/(2^4) for LoE purposes). I'll now give you all the energy output from Sol, via a Dyson shell (solid Dyson sphere around our sun, capturing all the energy released), about 3.846 × 1026 Watts, or 2^89 (rounding up to next power of 2). We'll ignore the age difference of Sol (4.5 B vs 15 B). There are maybe 10^24 stars, or 2^80. You can have them all. Even if the vast majority of those were as big as it gets for main sequence, ie. 500,000 x solar mass, that is only 2^19. Yours, for free. So, putting a Dyson shell around every star, that has ever been, for all time up until now, powering as many 1 W cpu cores at 4GHz as possible, would have produced about enough guesses to cover the range of 2 through 2^(100 + 88 + 89 + 32 + 80 + 4 + 19), or 2^(412). You would have had to been really lucky to guess one of the prime components (I.e. to get the private key) -- 1/2^(812), or about 1/10^244. That is one chance in: 100 000 000 (Or, with commas, 10,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000, 000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 ,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,00 0,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,0 00,000,000,000,000,000,000.) So, in short, "not impossible" would have to be considered an extraordinary understatement. And, if you happened to be that lucky, then yes, expensive but not impossible. Brian
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Ted, What I like about this message is that you have demonstrated the *potential* severability of these issues. Things are set up as they are for a matter of scaling. Clearly it ain't perfect, and as one of my mentors would say, that represents an opportunity. It's also pretty clear that we should be reviewing this stuff in consultation with ICANN's SSAC committee. Eliot On 9/12/13 7:21 PM, Theodore Ts'o wrote: > Fair enough, but if the goal is to prevent pervasive surveillance, > simply using a key exchange which provides perfect forward secrecy > will do that, even given the pathetic state of https security given > the realities of the web and the CA's out there. > > Still, I agree with the general precept that perfect should not enemy > of the better, and DNSSEC certainly adds value. I just get worried > about people who seem to think that DNSSEC is a panacea. > > - Ted > >
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Wed, 11 Sep 2013, Olafur Gudmundsson wrote: > > On Sep 10, 2013, at 8:17 PM, David Morris wrote: > > > > > > > On Wed, 11 Sep 2013, Brian E Carpenter wrote: > > > >> On 11/09/2013 09:59, Olafur Gudmundsson wrote: > >> ... > >>> My colleagues and I worked on OpenWrt routers to get Unbound to work > >>> there, what you need to do is to start DNS up in non-validating mode > >>> wait for NTP to fix time, then check if the link allows DNSSEC answers > >>> through, at which point you can enable DNSSEC validation. > >> > >> Hopefully you also flush the DNS cache as soon as NTP runs. Even so, > >> paranoia suggests that a dodgy IP address might still be cached in > >> some app. > > > > I think you can avoid that issue by having the device not pass traffic > > until the DNSSEC validation is enabled. Only the device needs the special > > permissive handling for this to work. > > > > You mean only allow NTP and DNS traffic in the beginning, until checks are > done? > In many cases we can get a reasonable time by writing the current time to a > NVRAM variable every 6 hours or so, but that > only helps for reboot. No, I mean that the Home class gateway device would not accept any traffic for it's inside network until it has DNSSEC validation and related NTP setup was completed. This would extend the apparent boot time a small amount of time relative to other components of the boot sequence. By not allowing thru traffic, I think the concern about DNS results being cached on the inside network would be a non-issue. And the gateway device controls its own cache so flushing it should not be an issue
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 12, 2013, at 1:49 PM, "Dickson, Brian" wrote: > In order to subvert or redirect a delegation, the TLD operator (or > registrar) would need to change the DNS server name/IP, and replace the DS > record(s). Someone who possesses the root key could in principle create a fake DNS hierarchy with relatively few strategic changes, and present it only to certain attack targets. This would be expensive, but not impossible. It would not work, for example, for dragnet-style surveillance.
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Thu, 12 Sep 2013, Theodore Ts'o wrote: Any co-ercing that happens has to be globally visible, if the target ensures he is using "random" nameservers to query for data. Not necessarily. First of all, an active attacker located close to the target can simply replace the DNS replies with bogus records, Not if I run DNS over TCP through tor. That's why I said "random" servers. Are they going to after a single target by being upstream of all the tor exit nodes? Even if they did, we should just run monitors for our own zones that also query for that data using tor. They won't know the difference between the monitor and their target. signed by the registrar's key which was either coerced or stolen by the NSA's Key "Recovery" Service. Secondly, if the web site has all of its nameservers run by the same organization (i.e., GoDadddy's DNS service), the nameservers could be set up to return the bogus DNS records only to specific IP addresses or specific IP ranges. See above. Finally, if you think the target can try to find random caching nameservers all across the networ to use, (a) there are certain environments where this is not allowed --- some ISP's or hotel/coffee shop/airline's networks require that you use their name server, and (b) for good and proper reasons, most nameservers have been configured not to allow recursive queries to random IP addresses. See above. But also, you can use various open resolvers. The Fedora Project even runs a few for dnssec-trigger that are accessable only via TCP - I'm hoping more people will put up TCP-only open resolvers, especially with: https://datatracker.ietf.org/doc/draft-wouters-edns-tcp-chain-query/ Furthermore, TLDs could institute a delay mechanism with respect to updating KSK/DS record so a compromised Registrar requesting an updated DS won't come into effect immediately, and the Registrant has time to react. A delay mechanism would only work if the TLD sent a notification of a changed KSK/DS record to the Registrant --- but would TLD have access to the contact information for the Registrant? Yes, the TLD runs their Registry with admin-c and tech-c contact information. Another method would be for the domain "lock" to get a delay of a few hours and/or a confirmation message to the registrant if the registrar changes the lock status. Paul
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Thu, 12 Sep 2013, Theodore Ts'o wrote: More importantly, what problem do people think DNSSEC is going to solve? It is still a hierarchical model of trust. So at the top, if you don't trust Verisign for the .COM domain and PIR for the .ORG domain (and for people who are worried about the NSA, both of these are US corporations), the whole system falls apart. Any co-ercing that happens has to be globally visible, if the target ensures he is using "random" nameservers to query for data. This should be detectable, and I hope that high value domains (like eff.org) ensure that they are monitoring DNS answers to see if any forged-with-private-key answers are seen in the wild. (eg RIPE Atlas?) Once we have proof of that, we can ponder about how to cut the US Government out of our DNS roots. (sadly, eff.org is still not signed and has no TLSA record. Likely due to their registrar not supporting it, but at least they could do DLV) And even if you believe Verisign and PIR are a paragons of virtue which are incorruptible (even when in a dark room when no one can see, as the old Chinese saying goes), what about all of the registrars? Their dynamic with their users and the market is the same as with CA's --- the market virtually guarantees a race to the bottom in terms of quality and prices. So beyond replacing names like "Comodo" with "Go Daddy", what benefit do you actually think would accrue? You'll still be dealing with a self-service security model, probably using e-mail based password recovery. As Tony said. You can pick a non-bottom one. Basically, DNSSEC maps almost identically to the previously unsolved problem. Not at all - targetted attacks with CAs are easy. Unlike with DNSSEC. Furthermore, TLDs could institute a delay mechanism with respect to updating KSK/DS record so a compromised Registrar requesting an updated DS won't come into effect immediately, and the Registrant has time to react. Paul
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Thu, Sep 12, 2013 at 04:46:01PM +, Ted Lemon wrote: > > The model for this sort of validation is really not on a per-client > basis, but rather depends on routine cross-validation by various > DNSSEC operators throughout the network. This will not necessarily > catch a really focused attack, so it's not a panacea, but it would > limit the scope of the threat for this sort of attack. Fair enough, but if the goal is to prevent pervasive surveillance, simply using a key exchange which provides perfect forward secrecy will do that, even given the pathetic state of https security given the realities of the web and the CA's out there. Still, I agree with the general precept that perfect should not enemy of the better, and DNSSEC certainly adds value. I just get worried about people who seem to think that DNSSEC is a panacea. - Ted
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 11, 2013, at 12:38 PM, Phillip Hallam-Baker wrote: >> >> I disagree. DNSSEC is not just DNS: its the only available, deployed, and >> (mostly) accessible global PKI currently in existence which also includes a >> constrained path of trust which follows already established business >> relationships. > > Except that virtually nobody uses DNSSEC and most of the registrars don't > support it. I strongly disagree: I had an easier time registering my DNSSEC test domain's DS records with the registrar than the nameservers themselves, using an obnoxious company that sponsors a NASCAR driver and has obnoxious TV ads. Comcast and Google Public DNS both validate DNSSEC on all requests. A small minority of clients can't fetch DNSSEC records, but most actually can, either through one of the recursive resolvers or over the Internet. > And then there is that other PKI that is actually used to support a trillion > odd dollars worth of global e-commerce per year. Which the NSA is man-in-the-middling with abandon, in due to no-small-part the lack of a constrained path of trust. Google has effectively given up on the TLS PKI for their own use in Chrome: they hardcode the Google sub-CA. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 12, 2013, at 1:21 PM, Theodore Ts'o wrote: > Still, I agree with the general precept that perfect should not enemy > of the better, and DNSSEC certainly adds value. I just get worried > about people who seem to think that DNSSEC is a panacea. Me too. It most certainly is not.
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
robert bownes wrote: > A 1pulse per second aligned to GPS is good to a few ns. Fairly > straightforward to plug into even a OpenWrt type of router. Turn on the pps > in NTP on the router and you are good to go. Faking GPS signal is trivially easy. Iraq successfully captured US unmanned plain, apparently by supplying it false location. Masataka Ohta
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Ted Lemon wrote: > This isn't _quite_ true. DNSSEC supports trust anchors at > any point in the hierarchy, and indeed I think the right > model for DNSSEC is that you would install trust anchors > for things you really care about, and manage them in the > same way that you manage your root trust anchor. E.g., > you'd install a trust anchor for your employer, and your > bank, and maybe your local town government. This is > all future UI work, of course. Operationally, that's not practical. Users can't manage their trust anchors securely. > Furthermore, if the root key is compromised and that is then > used to substitute a bogus key, it isn't that hard to notice > that this has happened, and indeed we ought to be > systematically noticing these things. So hacking the root > key is certainly a valid threat, but there is a great deal > more transparency in the DNSSEC system than in the TLS PKI, > and that should mean that the system is more robust in the > face of this kind of attack. According to your theory, we don't need DNSSEC, because cache poisoning attacks on plain DNS is easily detectable. Masataka Ohta
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 12, 2013, at 3:16 PM, "Dickson, Brian" wrote: > Excluding the direct methods of acquisition, let us consider the level of > effort involved in recreating the root key, by brute force. I think we can assume that they would use some fairly subtle attack to get the key, and would not brute force it, unless they know something we do not. E.g., they might capture it using TEMPEST-style or other EMI-based attacks, or by buying a sufficiency of key holders (which I suspect would be a lot harder at the moment, but might not always be as hard).
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 12, 2013, at 11:07 AM, Theodore Ts'o wrote: > Finally, if you think the target can try to find random caching > nameservers all across the networ to use, (a) there are certain > environments where this is not allowed --- some ISP's or hotel/coffee > shop/airline's networks require that you use their name server, and > (b) for good and proper reasons, most nameservers have been configured > not to allow recursive queries to random IP addresses. The model for this sort of validation is really not on a per-client basis, but rather depends on routine cross-validation by various DNSSEC operators throughout the network. This will not necessarily catch a really focused attack, so it's not a panacea, but it would limit the scope of the threat for this sort of attack.
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 12, 2013, at 2:35 PM, Phillip Hallam-Baker wrote: > It would work just fine if the attacker did not mind if the surveillance was > detected or actually wanted people to know they were being watched to > intimidate them. Yup,neither PKI nor DNSSEC address that threat model. For that you need really good steganography or other covert channels. Probably too specialized for us.
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Thu, Sep 12, 2013 at 2:07 PM, Ted Lemon wrote: > On Sep 12, 2013, at 1:49 PM, "Dickson, Brian" > wrote: > > In order to subvert or redirect a delegation, the TLD operator (or > > registrar) would need to change the DNS server name/IP, and replace the > DS > > record(s). > > Someone who possesses the root key could in principle create a fake DNS > hierarchy with relatively few strategic changes, and present it only to > certain attack targets. This would be expensive, but not impossible. It > would not work, for example, for dragnet-style surveillance. > > It would not work for covert dragnet surveillance. It would work just fine if the attacker did not mind if the surveillance was detected or actually wanted people to know they were being watched to intimidate them. -- Website: http://hallambaker.com/
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Thu, Sep 12, 2013 at 1:21 PM, Theodore Ts'o wrote: > On Thu, Sep 12, 2013 at 04:46:01PM +, Ted Lemon wrote: > > > > The model for this sort of validation is really not on a per-client > > basis, but rather depends on routine cross-validation by various > > DNSSEC operators throughout the network. This will not necessarily > > catch a really focused attack, so it's not a panacea, but it would > > limit the scope of the threat for this sort of attack. > > Fair enough, but if the goal is to prevent pervasive surveillance, > simply using a key exchange which provides perfect forward secrecy > will do that, even given the pathetic state of https security given > the realities of the web and the CA's out there. > > Still, I agree with the general precept that perfect should not enemy > of the better, and DNSSEC certainly adds value. I just get worried > about people who seem to think that DNSSEC is a panacea. > +1 DNSSEC is a very useful tool. But don't try to make it do things that it was never designed for. In particular, I bank with Bank of America, not bankamerica.com [1]. That has profound implications for the types of security that are possible with DNSSEC. Deployment of DNSSEC permits an Internet user to avoid a downgrade attack which is vital when you have an Internet that is insecure by default and security is the exception. That is what I want DNSSEC to address. Given Jim's original question, having time good to 1 hour seems perfectly acceptable for purposes of risk mitigation. If you need higher degrees of assurance then use machines that DO have a built in real time clock. If that is you think it is reasonable to use the DNS to publish information that changes more rapidly. When I started doing Internet stuff TTL on DNS records tended to be three days by default. The registries took 24 hours to reflect changes. As a general rule it is much more productive if people respect the fact that someone just might be suggesting a limitation of an infrastructure because they want to help solve a problem rather than dismissing everything as FUD. One of the main reasons it has taken so long to get DNSSEC to this stage is that honest attempts to make the system practical were treated as covert sabotage attempts. [1] Actually I don't it is an example. -- Website: http://hallambaker.com/
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 12, 2013, at 7:24 AM, Theodore Ts'o wrote: > It is still a hierarchical model of trust. So at the top, if you > don't trust Verisign for the .COM domain and PIR for the .ORG domain > (and for people who are worried about the NSA, both of these are US > corporations), the whole system falls apart. This isn't _quite_ true. DNSSEC supports trust anchors at any point in the hierarchy, and indeed I think the right model for DNSSEC is that you would install trust anchors for things you really care about, and manage them in the same way that you manage your root trust anchor. E.g., you'd install a trust anchor for your employer, and your bank, and maybe your local town government. This is all future UI work, of course. Furthermore, if the root key is compromised and that is then used to substitute a bogus key, it isn't that hard to notice that this has happened, and indeed we ought to be systematically noticing these things. So hacking the root key is certainly a valid threat, but there is a great deal more transparency in the DNSSEC system than in the TLS PKI, and that should mean that the system is more robust in the face of this kind of attack. That said, multiple independent systems used together, managed separately, will likely also add value, so TLS PKI + DNSSEC is probably better than TLS PKI or DNSSEC separately, modulo DoS attacks, which in this case would be easily detected and fixed.
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Thu, Sep 12, 2013 at 10:22:10AM -0400, Paul Wouters wrote: > > Any co-ercing that happens has to be globally visible, if the target > ensures he is using "random" nameservers to query for data. Not necessarily. First of all, an active attacker located close to the target can simply replace the DNS replies with bogus records, signed by the registrar's key which was either coerced or stolen by the NSA's Key "Recovery" Service. Secondly, if the web site has all of its nameservers run by the same organization (i.e., GoDadddy's DNS service), the nameservers could be set up to return the bogus DNS records only to specific IP addresses or specific IP ranges. Finally, if you think the target can try to find random caching nameservers all across the networ to use, (a) there are certain environments where this is not allowed --- some ISP's or hotel/coffee shop/airline's networks require that you use their name server, and (b) for good and proper reasons, most nameservers have been configured not to allow recursive queries to random IP addresses. > Furthermore, TLDs could institute a delay mechanism with respect to > updating KSK/DS record so a compromised Registrar requesting an updated > DS won't come into effect immediately, and the Registrant has time to > react. A delay mechanism would only work if the TLD sent a notification of a changed KSK/DS record to the Registrant --- but would TLD have access to the contact information for the Registrant? - Ted
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker wrote: > > The DNS is the naming infrastructure of the Internet. While it is in theory > possible to use the DNS to advertise very rapid changes to Internet > infrastructure, the practice is that the Internet infrastructure will look > almost exactly the same in one hour's time as it does right now. > > Using DNS data from 24 hours earlier might create reliability issues but > should never introduce a security risk. Anyone who is relying on the DNS for > data that is more time sensitive than 1 hour is doing it wrong. I disagree. DNSSEC is not just DNS: its the only available, deployed, and (mostly) accessible global PKI currently in existence which also includes a constrained path of trust which follows already established business relationships. Dynamic DNSSEC applications, where signatures are generated on the fly, are almost certainly going to be developed to utilize this infrastructure. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Wed, 11 Sep 2013, Joe Abley wrote: 1. We only need to know the current time to an accuracy of 1 hour. [RRSIG expiration times are specified with a granularity of a second, right? I appreciate that most people are generous with signature inception and expiration times in order to facilitate clock skew on validators, but I think "1 hour" needs some qualification.] The 1h came from the shortest RRSIG validity time in the chain to get to pool.ntp.org, but performing a handful of queries now, I cannot find that magical RRSIG with the 1h validity period. Note: I also once ran into bad clocks due to dual boot systems with Windows and Daylight Savings Time, so I explicitely set inception time to -2h. One hour is not enough on doubly broken systems. Paul
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Theodore Ts'o wrote: > > Their dynamic with their users and the market is the same as with CA's > --- the market virtually guarantees a race to the bottom in terms of > quality and prices. So beyond replacing names like "Comodo" with "Go > Daddy", what benefit do you actually think would accrue? You'll still > be dealing with a self-service security model, probably using e-mail > based password recovery. But if you care about security you can - with useful effect - choose a registrar with better security processes, and you can use a registry lock to prevent other registrars from undermining that security. There isn't a way to prevent other CAs undermining your security, so choosing a "more secure" CA has no useful effect. (Certificate Transparency should help, though.) Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Theodore Ts'o wrote: > More importantly, what problem do people think DNSSEC is going to > solve? Insufficient revenue of registries. > It is still a hierarchical model of trust. So at the top, if you > don't trust Verisign for the .COM domain and PIR for the .ORG domain > (and for people who are worried about the NSA, both of these are US > corporations), the whole system falls apart. Right. PKI is fundamentally broken, because its fundamental assumption that trusted third parties could exist is a total fallacy. Masataka Ohta
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Wed, Sep 11, 2013 at 03:38:21PM -0400, Phillip Hallam-Baker wrote: > > I disagree. DNSSEC is not just DNS: its the only available, deployed, and > > (mostly) accessible global PKI currently in existence which also includes a > > constrained path of trust which follows already established business > > relationships. > > Except that virtually nobody uses DNSSEC and most of the registrars don't > support it. More importantly, what problem do people think DNSSEC is going to solve? It is still a hierarchical model of trust. So at the top, if you don't trust Verisign for the .COM domain and PIR for the .ORG domain (and for people who are worried about the NSA, both of these are US corporations), the whole system falls apart. And even if you believe Verisign and PIR are a paragons of virtue which are incorruptible (even when in a dark room when no one can see, as the old Chinese saying goes), what about all of the registrars? Their dynamic with their users and the market is the same as with CA's --- the market virtually guarantees a race to the bottom in terms of quality and prices. So beyond replacing names like "Comodo" with "Go Daddy", what benefit do you actually think would accrue? You'll still be dealing with a self-service security model, probably using e-mail based password recovery. Sure, authenticating DNS queries when previously they were completely insecured is a good thing. And if the PKI infrastructure for DNSSEC is different from that of x509 certificate, maybe that increases the difficulty a little for the attacker. But I get really worried when people say that DNSSEC is somehow going to magically solve the PKI problem. Basically, DNSSEC maps almost identically to the previously unsolved problem. - Ted
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Arturo Servin wrote: >>> 3) A relying party thus requires a demonstration that is secure against a >>> replay attack from one or more trusted parties to be assured that the time >>> assertion presented is current but this need not necessarily be the same as >>> the source of the signed time assertion itself. >> >>> The real design decision is who you decide you are going to rely on for >>> (3). TLS is proof against replay attack due to the exchange of nonces. >> >> How can you get secure time to securely confirm that a certificate >> of TLS has not expired? >> >> Use yet another PKI? > No, you have your own clock. No, you can't, because the original assumption by Jim is: > 1) DNSSEC needs to have the time within one hour. But these > devices do not have TOY clocks (and arguably, never will, nor > even probably should ever have them). Even if you can, you can't be sure that the clock is accurate enough. Thus, PKIs requiring time stamps for expiration or CRL are broken. Masataka Ohta
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On 9/12/13 3:02 AM, Masataka Ohta wrote: > Phillip Hallam-Baker wrote: > >> 3) A relying party thus requires a demonstration that is secure against a >> replay attack from one or more trusted parties to be assured that the time >> assertion presented is current but this need not necessarily be the same as >> the source of the signed time assertion itself. > >> The real design decision is who you decide you are going to rely on for >> (3). TLS is proof against replay attack due to the exchange of nonces. > > How can you get secure time to securely confirm that a certificate > of TLS has not expired? > > Use yet another PKI? > > Masataka Ohta > No, you have your own clock. .as
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Phillip Hallam-Baker wrote: > > 2. The current time is a matter of convention rather than a natural > property. It is therefore impossible to determine the time without > reference to at least one trusted party. Preferably more than one so you can use quorum agreement and minimize the amount of trust you put in any single time reference. > 4) In the case of DNSSEC the window of vulnerability is actually fairly > small since rewinding the time to a date in the past only helps an attacker > if they had compromised the system on that date. So if you rely on RRSIG timestamps or SOA serial numbers to get the time, an attacker that manages to compromise DNSSEC can replay that compromise indefinitely. > The real design decision is who you decide you are going to rely on for > (3). TLS is proof against replay attack due to the exchange of nonces. Right. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Phillip Hallam-Baker wrote: > 3) A relying party thus requires a demonstration that is secure against a > replay attack from one or more trusted parties to be assured that the time > assertion presented is current but this need not necessarily be the same as > the source of the signed time assertion itself. > The real design decision is who you decide you are going to rely on for > (3). TLS is proof against replay attack due to the exchange of nonces. How can you get secure time to securely confirm that a certificate of TLS has not expired? Use yet another PKI? Masataka Ohta
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Wed, Sep 11, 2013 at 12:08 PM, Paul Wouters wrote: > On Wed, 11 Sep 2013, Joe Abley wrote: > > >>> 1. We only need to know the current time to an accuracy of 1 hour. >>> >> >> [RRSIG expiration times are specified with a granularity of a second, >> right? >> >> I appreciate that most people are generous with signature inception and >> expiration times in order to facilitate clock skew on validators, but I >> think "1 hour" needs some qualification.] >> > > The 1h came from the shortest RRSIG validity time in the chain to get to > pool.ntp.org, but performing a handful of queries now, I cannot find > that magical RRSIG with the 1h validity period. > > Note: I also once ran into bad clocks due to dual boot systems with > Windows and Daylight Savings Time, so I explicitely set inception time > to -2h. One hour is not enough on doubly broken systems. The DNS is the naming infrastructure of the Internet. While it is in theory possible to use the DNS to advertise very rapid changes to Internet infrastructure, the practice is that the Internet infrastructure will look almost exactly the same in one hour's time as it does right now. Using DNS data from 24 hours earlier might create reliability issues but should never introduce a security risk. Anyone who is relying on the DNS for data that is more time sensitive than 1 hour is doing it wrong. -- Website: http://hallambaker.com/
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On 2013-09-11, at 11:43, Phillip Hallam-Baker wrote: > OK lets consider the trust requirements here. > > 1. We only need to know the current time to an accuracy of 1 hour. [RRSIG expiration times are specified with a granularity of a second, right? I appreciate that most people are generous with signature inception and expiration times in order to facilitate clock skew on validators, but I think "1 hour" needs some qualification.] > 2. The current time is a matter of convention rather than a natural property. > It is therefore impossible to determine the time without reference to at > least one trusted party. > > 2a) A trusted party that asserts that the current time is set to a date in > the future can perform a denial of service attack on a relying party but one > that is easily detected. > > 2b) It is a simple matter for the trusted party to provide a signed assertion > that the current time is after the Date-Time X. The hard part is ensuring > that the relying party can access an up to date version of the current time > assertion. > > 2c) DNSSEC already provides an abundance of such assertions. If the > signatures on the .com zone are claiming a date in the future then the whole > viability of DNSSEC collapses. > > 3) A relying party thus requires a demonstration that is secure against a > replay attack from one or more trusted parties to be assured that the time > assertion presented is current but this need not necessarily be the same as > the source of the signed time assertion itself. > > 4) In the case of DNSSEC the window of vulnerability is actually fairly small > since rewinding the time to a date in the past only helps an attacker if they > had compromised the system on that date. [or if they had intercepted, stored and replayed a signed response at a later time when the current response would be different] > The real design decision is who you decide you are going to rely on for (3). > TLS is proof against replay attack due to the exchange of nonces. I think that's deeper than where we are right now. Before we consider mechanisms for gauging the accuracy of a local clock, we need consensus on the general approach, e.g. the state machine implied by draft-jabley-dnsop-validator-bootstrap or something different but analogous. Joe
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Wed, 11 Sep 2013, Olafur Gudmundsson wrote: I think you can avoid that issue by having the device not pass traffic until the DNSSEC validation is enabled. Only the device needs the special permissive handling for this to work. You mean only allow NTP and DNS traffic in the beginning, until checks are done? In many cases we can get a reasonable time by writing the current time to a NVRAM variable every 6 hours or so, but that only helps for reboot. And if you think of laptop and/or phone, add "hotspot detection" to this isolation mode. It's harder because it needs a "private browser window" type state. Paul
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
OK lets consider the trust requirements here. 1. We only need to know the current time to an accuracy of 1 hour. 2. The current time is a matter of convention rather than a natural property. It is therefore impossible to determine the time without reference to at least one trusted party. 2a) A trusted party that asserts that the current time is set to a date in the future can perform a denial of service attack on a relying party but one that is easily detected. 2b) It is a simple matter for the trusted party to provide a signed assertion that the current time is after the Date-Time X. The hard part is ensuring that the relying party can access an up to date version of the current time assertion. 2c) DNSSEC already provides an abundance of such assertions. If the signatures on the .com zone are claiming a date in the future then the whole viability of DNSSEC collapses. 3) A relying party thus requires a demonstration that is secure against a replay attack from one or more trusted parties to be assured that the time assertion presented is current but this need not necessarily be the same as the source of the signed time assertion itself. 4) In the case of DNSSEC the window of vulnerability is actually fairly small since rewinding the time to a date in the past only helps an attacker if they had compromised the system on that date. The real design decision is who you decide you are going to rely on for (3). TLS is proof against replay attack due to the exchange of nonces.
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Wed, Sep 11, 2013 at 12:26 PM, Nicholas Weaver wrote: > > On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker > wrote: > > > > The DNS is the naming infrastructure of the Internet. While it is in > theory possible to use the DNS to advertise very rapid changes to Internet > infrastructure, the practice is that the Internet infrastructure will look > almost exactly the same in one hour's time as it does right now. > > > > Using DNS data from 24 hours earlier might create reliability issues but > should never introduce a security risk. Anyone who is relying on the DNS > for data that is more time sensitive than 1 hour is doing it wrong. > > I disagree. DNSSEC is not just DNS: its the only available, deployed, and > (mostly) accessible global PKI currently in existence which also includes a > constrained path of trust which follows already established business > relationships. > Except that virtually nobody uses DNSSEC and most of the registrars don't support it. And then there is that other PKI that is actually used to support a trillion odd dollars worth of global e-commerce per year. DNSSEC has been about to exist ever since I started on the Web over two decades ago now. It is still not in use to support any business transactions. So to present it as the only PKI when it isn't yet deployed is showing a distinct lack of common sense and acceptance of reality. -- Website: http://hallambaker.com/
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Hi - >From: Olafur Gudmundsson >Sent: Sep 11, 2013 7:19 AM >To: Evan Hunt >Cc: "dn...@ietf.org WG" , "ietf@ietf.org TF" >Subject: Re: [DNSOP] Practical issues deploying DNSSEC into the home. ... >RRSIG on the SOA or NS or DNSKEY also is fine timestamp except when it is a >replay attack or a forgery, ... RFC 3414 separates the notion of timeliness (replay detection) from authentication without requiring NTP or overly elaborate clock acquisition dances. Some of the ideas from that protocol's design might be useful in addressing this problem. Randy
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote: > My colleagues and I worked on OpenWrt routers to get Unbound to work > there, what you need to do is to start DNS up in non-validating mode wait > for NTP to fix time, then check if the link allows DNSSEC answers > through, at which point you can enable DNSSEC validation. That's roughly what we did with BIND on OpenWrt/CeroWrt as well. We also discussed hacking NTP to set the CD bit on its initial DNS queries, but I don't think any of the code made it upstream. My real recommendation would be to run an NTP pool in an anycast cloud of well-known v4 and v6 addresses guaranteed to be reliable over a period of years. NTP could then fall back to those addresses if unable to look up the server it was configured to use. DNS relies on a well-known set of root server addresses for bootstrapping; I don't see why NTP shouldn't do the same. (Actually... the root nameservers could *almost* provide a workable time tick for bootstrapping purposes right now: the SOA record for the root zone encodes today's date in the serial number. So you do the SOA lookup, set your system clock, attempt validation; on failure, set the clock an hour forward and try again; on success, use NTP to fine-tune. Klugey! :) ) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc.
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 11, 2013, at 7:19 AM, Olafur Gudmundsson wrote: >> (Actually... the root nameservers could *almost* provide a workable time >> tick for bootstrapping purposes right now: the SOA record for the root >> zone encodes today's date in the serial number. So you do the SOA lookup, >> set your system clock, attempt validation; on failure, set the clock an >> hour forward and try again; on success, use NTP to fine-tune. Klugey! :) ) >> >> - > > RRSIG on the SOA or NS or DNSKEY also is fine timestamp except when it is a > replay attack or a forgery, This can actually do it down to 1s precision except in the case of a replay attack with a dynamically signed name (and if you are facing a replay attack, you can't trust NTP anyway!): E.g., this name: dig +dnssec 10sec100ttlsig.netalyzr-dnssec.com @8.8.8.8 has a RRSIG that expires in +10 seconds (ALWAYS), but has a TTL on the record that expires in 100 s. This is an example name on my server designed for allowing single-lookup clockdrift testing on DNSSEC validators. (The signature is also generated on-the-fly every second its requested, and a subsequent addition will include the ability to add a NONCE to guarantee cache-busting, too). -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 10, 2013, at 8:17 PM, David Morris wrote: > > > On Wed, 11 Sep 2013, Brian E Carpenter wrote: > >> On 11/09/2013 09:59, Olafur Gudmundsson wrote: >> ... >>> My colleagues and I worked on OpenWrt routers to get Unbound to work there, >>> what you need to do is to start DNS up in non-validating mode >>> wait for NTP to fix time, then check if the link allows DNSSEC answers >>> through, at which point you can enable DNSSEC validation. >> >> Hopefully you also flush the DNS cache as soon as NTP runs. Even so, >> paranoia suggests that a dodgy IP address might still be cached in >> some app. > > I think you can avoid that issue by having the device not pass traffic > until the DNSSEC validation is enabled. Only the device needs the special > permissive handling for this to work. > You mean only allow NTP and DNS traffic in the beginning, until checks are done? In many cases we can get a reasonable time by writing the current time to a NVRAM variable every 6 hours or so, but that only helps for reboot. Olafur
Re: Practical issues deploying DNSSEC into the home.
On Sep 10, 2013, at 7:17 PM, Brian E Carpenter wrote: > On 11/09/2013 09:59, Olafur Gudmundsson wrote: > ... >> My colleagues and I worked on OpenWrt routers to get Unbound to work there, >> what you need to do is to start DNS up in non-validating mode >> wait for NTP to fix time, then check if the link allows DNSSEC answers >> through, at which point you can enable DNSSEC validation. > > Hopefully you also flush the DNS cache as soon as NTP runs. Even so, > paranoia suggests that a dodgy IP address might still be cached in > some app. > >Brian Flushing cache is a good idea, and dnssec-trigger does this when it "upgrades" the unbound from recursor to validator. Olafur
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 10, 2013, at 6:45 PM, Evan Hunt wrote: > On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote: >> My colleagues and I worked on OpenWrt routers to get Unbound to work >> there, what you need to do is to start DNS up in non-validating mode wait >> for NTP to fix time, then check if the link allows DNSSEC answers >> through, at which point you can enable DNSSEC validation. > > That's roughly what we did with BIND on OpenWrt/CeroWrt as well. We > also discussed hacking NTP to set the CD bit on its initial DNS queries, > but I don't think any of the code made it upstream. > Not sure if this will work in all cases, as a paranoid resolver might only ignore the CD bit for the actual answer not for the DNS records needed to navigate to the answer. > My real recommendation would be to run an NTP pool in an anycast cloud of > well-known v4 and v6 addresses guaranteed to be reliable over a period of > years. NTP could then fall back to those addresses if unable to look up the > server it was configured to use. DNS relies on a well-known set of root > server addresses for bootstrapping; I don't see why NTP shouldn't do the > same. > This is something worth suggesting, and > (Actually... the root nameservers could *almost* provide a workable time > tick for bootstrapping purposes right now: the SOA record for the root > zone encodes today's date in the serial number. So you do the SOA lookup, > set your system clock, attempt validation; on failure, set the clock an > hour forward and try again; on success, use NTP to fine-tune. Klugey! :) ) > > - RRSIG on the SOA or NS or DNSKEY also is fine timestamp except when it is a replay attack or a forgery, Olafur
Re: Practical issues deploying DNSSEC into the home.
[cc'ed to a more approriate IETF wg] On Sep 10, 2013, at 11:55 AM, Jim Gettys wrote: > Ted T'so referred to a conversation we had last week. Let me give the > background. > > Dave Taht has been doing an advanced version of OpenWrt for our bufferbloat > work (called CeroWrt http://www.bufferbloat.net/projects/cerowrt/wiki/Wiki). > Of course, we both want things other than just bufferbloat, as you can see by > looking at that page (and you want to run in place of what you run today, > given how broken and dated home router firmware from manufacturers generally > is). Everything possible gets pushed upstream into OpenWrt as quickly as > possible; but CeroWrt goes beyond where OpenWrt is in quite a few ways. > > I was frustrated by Homenet's early belief's (on no data) that lots of things > weren't feasible due to code/data footprint; both Dave and I knew better from > previous work on embedded hardware. As example, Dave put a current version > of bind 9 into the build (thereby proving that having a full function name > service in your home router was completely feasible; that has aided > discussions in the working group) since. > > We uncovered two practical problems, both of which need to be solved to > enable full DNSSEC deployment into the home: > > 1) DNSSEC needs to have the time within one hour. But these devices do not > have TOY clocks (and arguably, never will, nor even probably should ever have > them). > > So how do you get the time after you power on the device? The usual answer > is "use ntp". Except you can't do a DNS resolve when your time is incorrect. > You have a chicken and egg problem to resolve/hack around :-(. > > Securely bootstrapping time in the Internet is something I believe needs > doing and being able to do so over wireless links, not just relying on > wired links. > > 2) when you install a new home router, you may want to generate certificates > for that home domain (particularly so it can be your primary name server, > which you'd really like to be under your control anyway, rather than > delegating to someone else who could either intentionally on unintentionally > subvert your domain). > > Right now, on that class hardware, there is a dearth of entropy available, > causing such certificate generation to be painful/impossible without human > intervention, which we know home users don't do. These SOC's do not have > hardware RNG's, and we can't trust them either blindly. Ted's working on that > situation in Linux; it is probably a case of "the enemy of the good is the > perfect", but certainly I'm now much more paranoid than I once was. > > See: https://plus.google.com/117091380454742934025/posts/XeApV5DKwAj > > Jim > My colleagues and I worked on OpenWrt routers to get Unbound to work there, what you need to do is to start DNS up in non-validating mode wait for NTP to fix time, then check if the link allows DNSSEC answers through, at which point you can enable DNSSEC validation. see: https://www.dnssec-deployment.org/index.php/2012/03/a-validating-recursive-resolver-on-a-70-home-router/ We also discovered that some cheap devices like this will do NTP at startup and never again that combined with long up-time and bad clocks caused the Validators to start rejecting signatures due to the time on the signatures. The big issue is that validator implementors assume that it runs on good hardware with good links, thus it is safe to enable DNSSEC out of the gate. We need either have resolvers come up in recursive mode and tool like dnsec-trigger or our scripts change the behavior to validator after that has been deemed safe, or build the checking into the validators. The same can be said of devices that have been installed from media or have been turned off for a long time (say month or more), in these cases starting up in validating mode only only turns the device into a brick. Olafur
Re: Practical issues deploying DNSSEC into the home.
On 2013-09-10, at 16:52, Russ Housley wrote: > NTP can be used to get time from an IP address. I understand all of the > reasons why a DNS name is preferred, but this a bootstrapping problem. Retrieval of root zone KSK trust anchors requires a DNS name, however (and you can't assume that the active KSK when the router left the factory is the same as the active KSK when the router was taken out of the box). Joe
Re: Practical issues deploying DNSSEC into the home.
On Wed, 11 Sep 2013, Brian E Carpenter wrote: > On 11/09/2013 09:59, Olafur Gudmundsson wrote: > ... > > My colleagues and I worked on OpenWrt routers to get Unbound to work there, > > what you need to do is to start DNS up in non-validating mode > > wait for NTP to fix time, then check if the link allows DNSSEC answers > > through, at which point you can enable DNSSEC validation. > > Hopefully you also flush the DNS cache as soon as NTP runs. Even so, > paranoia suggests that a dodgy IP address might still be cached in > some app. I think you can avoid that issue by having the device not pass traffic until the DNSSEC validation is enabled. Only the device needs the special permissive handling for this to work.
Practical issues deploying DNSSEC into the home.
Ted T'so referred to a conversation we had last week. Let me give the background. Dave Taht has been doing an advanced version of OpenWrt for our bufferbloat work (called CeroWrt http://www.bufferbloat.net/projects/cerowrt/wiki/Wiki). Of course, we both want things other than just bufferbloat, as you can see by looking at that page (and you want to run in place of what you run today, given how broken and dated home router firmware from manufacturers generally is). Everything possible gets pushed upstream into OpenWrt as quickly as possible; but CeroWrt goes beyond where OpenWrt is in quite a few ways. I was frustrated by Homenet's early belief's (on no data) that lots of things weren't feasible due to code/data footprint; both Dave and I knew better from previous work on embedded hardware. As example, Dave put a current version of bind 9 into the build (thereby proving that having a full function name service in your home router was completely feasible; that has aided discussions in the working group) since. We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is "use ntp". Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. Securely bootstrapping time in the Internet is something I believe needs doing and being able to do so over wireless links, not just relying on wired links. 2) when you install a new home router, you may want to generate certificates for that home domain (particularly so it can be your primary name server, which you'd really like to be under your control anyway, rather than delegating to someone else who could either intentionally on unintentionally subvert your domain). Right now, on that class hardware, there is a dearth of entropy available, causing such certificate generation to be painful/impossible without human intervention, which we know home users don't do. These SOC's do not have hardware RNG's, and we can't trust them either blindly. Ted's working on that situation in Linux; it is probably a case of "the enemy of the good is the perfect", but certainly I'm now much more paranoid than I once was. See: https://plus.google.com/117091380454742934025/posts/XeApV5DKwAj Jim
Re: Practical issues deploying DNSSEC into the home.
Jim: > 1) DNSSEC needs to have the time within one hour. But these devices do not > have TOY clocks (and arguably, never will, nor even probably should ever have > them). > > So how do you get the time after you power on the device? The usual answer > is "use ntp". Except you can't do a DNS resolve when your time is incorrect. > You have a chicken and egg problem to resolve/hack around :-(. > > Securely bootstrapping time in the Internet is something I believe needs > doing and being able to do so over wireless links, not just relying on > wired links. NTP can be used to get time from an IP address. I understand all of the reasons why a DNS name is preferred, but this a bootstrapping problem. RFC 5906 offers a way for NTP responses to be authenticated. So, if the IP address points to a NTP server that will give back a signed response, then the solution seems pretty straightforward. Of course, the vendor will need to make sure that one or more NTP servers are available, and make sure that the public keys are in place to validate the signed NTP responses. Over time these could change, but that could be handled by firmware updates. Many installation procedures include fetching the latest firmware, but DNS and routing need to be working for that to work in this bootstrap environment. Hopefully the firmware is authenticated too. RFC 4108 offers one approach to solving that problem. Russ
Re: Practical issues deploying DNSSEC into the home.
On 2013-09-10, at 12:58, Michael Richardson wrote: >> But I'm still thinking of a scheme involving insecure ntp lookups for >> pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow >> down the current time. Of course, all of that is vulnerable to replay >> attacks. > > I think that the best bet is to just turn off the time part of the DNSSEC > validation until the time is considered sane. That's what we propose, in essence, in draft-jabley-dnsop-validator-bootstrap: 3. Summary of Approach A validator that has no valid trust anchor initialises itself as follows. 3.1. Initial State A validator in its initial state is capable of sending and receiving DNS queries and responses, but is not capable of validating signatures received in responses. A validator must confirm that its local clock is sufficiently accurate before trust anchors can be established, and before processing of DNSSEC signatures can proceed. Discussion of timing considerations can be found in Section 4. 3.2. Trust Anchor Retrieval Once the local clock has been synchronised, a validator may proceed to gather candidate trust anchors for consideration. Discussion of trust anchor retrieval can be found in Section 5. 3.3. Trust Anchor Selection Once a set of candidate trust anchors has been obtained, a validator attempts to find one trust anchor in the set which is appropriate for use. This process involves verification of cryptographic signatures, and is discussed in Section 6. 3.4. Full Operation The validator now has an accurate trust anchor for the root zone, and is capable of validating signatures on responses from the DNS. We specify clock sync before trust anchor retrieval because trust anchors are published in a bundle with date ranges within which they should be considered suitable for use. Clock sync before validation makes sense for reasons already mentioned. Joe
Re: Practical issues deploying DNSSEC into the home.
I faced this problem in Omnibroker. One answer is that DNS is an infrastructure for resolving Internet labels to Internet resources including IP addresses. It is thus the only Internet infrastructure where infrastructure providers may reasonably be expected to maintain long term IP addresses by nature of their function. So in omnibroker, the idea is that it is a protocol to replace the communication between a client and a recursive resolver. This allows the addition of security features that are essential in the client-resolver loop that the DNS protocol does not provide and it is pointless to attempt to add. For example, mutual authentication. If the DNS resolver is going to do recursive resolution and DNSSEC validation then it had better validate the clients from which it accepts queries or it will get DoS attacked very quickly. To support the mutual auth between the omnibroker client and service I establish a context that consists of a set of services which each specify an IP address, port and shared secret. This means that it is very easy to support an authenticated 'time check' protocol. For cryptographic purposes we don't particularly care about the clocks being synchronized to better than a minute.
Re: Practical issues deploying DNSSEC into the home.
Hi Jim, At 08:55 10-09-2013, Jim Gettys wrote: We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is "use ntp". Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. That problem has been bothering me for a while. There can be a leap of faith at startup to get the correct time. DNSSEC can be done after that. Regards, -sm
Re: Practical issues deploying DNSSEC into the home.
On 11/09/2013 09:59, Olafur Gudmundsson wrote: ... > My colleagues and I worked on OpenWrt routers to get Unbound to work there, > what you need to do is to start DNS up in non-validating mode > wait for NTP to fix time, then check if the link allows DNSSEC answers > through, at which point you can enable DNSSEC validation. Hopefully you also flush the DNS cache as soon as NTP runs. Even so, paranoia suggests that a dodgy IP address might still be cached in some app. Brian
Re: Practical issues deploying DNSSEC into the home.
Paul Wouters wrote: > > One solution is "tlsdate" which uses the installed bundled CA (or comes > with its own) and runs TLS against a bunch of well known large sites > (using insecure DNS) and sets the time based on the TLS handshakes. I believe tlsdate currently only gets the time from one server. It would be nice if it could determine the time based on agreement of a quorum of diverse servers, so that no single source of time needs to be trusted. (I have talked about this with Jacob Appelbaum but I haven't had time to do anything about it.) Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
Re: Practical issues deploying DNSSEC into the home.
Paul Wouters wrote: > /dev/random references into /dev/urandom. You are most likely better of > giving the device a webgui and using the clients javascript to generate > randomness. (yes I know, I just said to use javascript for private > keys) I agree --- generate the certificates in the web UI. I don't think that this needs the private key to be created in javascript, just for a .js function to collect some entropy and push it into /dev/random. > But I'm still thinking of a scheme involving insecure ntp lookups for > pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow > down the current time. Of course, all of that is vulnerable to replay > attacks. I think that the best bet is to just turn off the time part of the DNSSEC validation until the time is considered sane. That limits the replay attack that can be done to replaying previous values for pool.ntp.org. The IP addreses returned might no longer be NTP clocks, and this could be annoying for those IPs involved, if there was some kind of widespread denial of service attack. Note that the NTP transaction is not protected at all by the DNSSEC, so if the attacker is on-path and can do this replay attack, they can also just attack the NTP transaction. > Also, I believe the rasberry pi's, having the same problem, have a > "hwclock" service that saves a timestamp on shutdown to the filesystem > and loads it on boot. That solves the issue for quick reboots. That also prevents going backwards in time, which is good. Storing it in config eeprom may be better than flash. > Another method is the last access time of the filesystem. But I'm not > sure if that's a linux/ext4+ only feature, or whether the filesystems > in embedded devices have a similar value stored somewhere. In general, they want to avoid any writes to the flash, so updating that value is a not desireable. -- Michael Richardson , Sandelman Software Works pgp6bbR419buV.pgp Description: PGP signature
Re: Practical issues deploying DNSSEC into the home.
On Tue, 10 Sep 2013, Jim Gettys wrote: We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is "use ntp". Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. Securely bootstrapping time in the Internet is something I believe needs doing and being able to do so over wireless links, not just relying on wired links. One solution is "tlsdate" which uses the installed bundled CA (or comes with its own) and runs TLS against a bunch of well known large sites (using insecure DNS) and sets the time based on the TLS handshakes. 2) when you install a new home router, you may want to generate certificates for that home domain (particularly so it can be your primary name server, which you'd really like to be under your control anyway, rather than delegating to someone else who could either intentionally on unintentionally subvert your domain). Right now, on that class hardware, there is a dearth of entropy available, causing such certificate generation to be painful/impossible without human intervention, which we know home users don't do. These SOC's do not have hardware RNG's, and we can't trust them either blindly. Ted's working on that situation in Linux; it is probably a case of "the enemy of the good is the perfect", but certainly I'm now much more paranoid than I once was. Be aware openwrt has a history (with openswan) to blindly change /dev/random references into /dev/urandom. You are most likely better of giving the device a webgui and using the clients javascript to generate randomness. (yes I know, I just said to use javascript for private keys) But I'm still thinking of a scheme involving insecure ntp lookups for pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow down the current time. Of course, all of that is vulnerable to replay attacks. Also, I believe the rasberry pi's, having the same problem, have a "hwclock" service that saves a timestamp on shutdown to the filesystem and loads it on boot. That solves the issue for quick reboots. Another method is the last access time of the filesystem. But I'm not sure if that's a linux/ext4+ only feature, or whether the filesystems in embedded devices have a similar value stored somewhere. Paul
Re: Practical issues deploying DNSSEC into the home.
Hi Jim, On 2013-09-10, at 11:55, Jim Gettys wrote: > We uncovered two practical problems, both of which need to be solved to > enable full DNSSEC deployment into the home: > > 1) DNSSEC needs to have the time within one hour. But these devices do not > have TOY clocks (and arguably, never will, nor even probably should ever have > them). > > So how do you get the time after you power on the device? The usual answer > is "use ntp". Except you can't do a DNS resolve when your time is incorrect. > You have a chicken and egg problem to resolve/hack around :-(. > > Securely bootstrapping time in the Internet is something I believe needs > doing and being able to do so over wireless links, not just relying on > wired links. Dave and I wrote up a proposal for this, which may be of interest. If you find this document, let me know and we can work to rejuvenate it (it withered on the I-D vine). http://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00 > 2) when you install a new home router, you may want to generate certificates > for that home domain (particularly so it can be your primary name server, > which you'd really like to be under your control anyway, rather than > delegating to someone else who could either intentionally on unintentionally > subvert your domain). I think as a starting point, you could safely assume that any local domain you host for the purpose of home users could be unsigned. Users behind the home gateway are trusting the cache on the home gateway anyway; serving signed, authoritative local data doesn't seem like it would add much benefot over serving the same data unsigned. Joe
