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 glen.wi...@gmail.com 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 e...@isc.org 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 e...@isc.org 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.
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.
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.
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.
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 9/12/13 2:07 PM, Ted Lemon ted.le...@nominum.com wrote: On Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com 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.
On 9/12/13 7:24 AM, Theodore Ts'o ty...@mit.edu 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 Sep 12, 2013, at 7:24 AM, Theodore Ts'o ty...@mit.edu 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.
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 e...@isc.org 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.
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.
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.
Phillip Hallam-Baker hal...@gmail.com 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.finch d...@dotat.at http://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.
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.
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 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.
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.
Theodore Ts'o ty...@mit.edu 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.finch d...@dotat.at http://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.
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.
On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker hal...@gmail.com 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 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 12, 2013, at 7:24 AM, Theodore Ts'o ty...@mit.edu 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 1:21 PM, Theodore Ts'o ty...@mit.edu 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 Thu, Sep 12, 2013 at 2:07 PM, Ted Lemon ted.le...@nominum.com wrote: On Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com 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 Sep 12, 2013, at 2:35 PM, Phillip Hallam-Baker hal...@gmail.com 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 Sep 12, 2013, at 11:07 AM, Theodore Ts'o ty...@mit.edu 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 3:16 PM, Dickson, Brian bdick...@verisign.com 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.
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.
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.
On Sep 12, 2013, at 1:21 PM, Theodore Ts'o ty...@mit.edu 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.
On Sep 11, 2013, at 12:38 PM, Phillip Hallam-Baker hal...@gmail.com 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 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 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, 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 Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com 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 Wed, 11 Sep 2013, Olafur Gudmundsson wrote: On Sep 10, 2013, at 8:17 PM, David Morris d...@xpasc.com 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 10, 2013, at 6:45 PM, Evan Hunt e...@isc.org 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: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 10, 2013, at 8:17 PM, David Morris d...@xpasc.com 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: [DNSOP] Practical issues deploying DNSSEC into the home.
On Sep 11, 2013, at 7:19 AM, Olafur Gudmundsson o...@ogud.com 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 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.
Hi - From: Olafur Gudmundsson o...@ogud.com Sent: Sep 11, 2013 7:19 AM To: Evan Hunt e...@isc.org Cc: dn...@ietf.org WG dn...@ietf.org, ietf@ietf.org TF ietf@ietf.org 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 Wed, Sep 11, 2013 at 12:26 PM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker hal...@gmail.com 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.
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, 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.
On 2013-09-11, at 11:43, Phillip Hallam-Baker hal...@gmail.com 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, Sep 11, 2013 at 12:08 PM, Paul Wouters p...@nohats.ca 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/
