Also, despite my earlier google queries about DNSSEC, everything I was reading was pretty dry. The magic phrase to google for is "DNSSEC sucks"--that gets you the interesting stuff.
I don't understand why your criticism of DNSSEC focuses on TLS vs. DNSSEC.
DNS is a scalable global key-value store, and DNSSEC allows owners of namespaces to sign their own key pairs and delegate to sub-namespaces. If you can make the case that _that_ is not valuable, or how that is accomplished by other means, I am curious. But TLS vs. DNSSEC doesn't cut it.
Yes, DNSSEC/DANE can make TLS work better. It provides a straightforward way to pin an entire zone tree while allowing site owner modifications. Your example of Ghadaffi and Bit.ly is silly, because the status quo is that governments already have access to CA keys able to issue for any server. Restricting to a single zone can only improve that.
I don't know how you can claim NSEC3 is a grotesque hack without noting that it is equally grotesque to pretend that your DNS records are private. If I wanted to collect the BoA zone, I would setup recursive nameservers on the coffee shops' wifi within a quarter mile of their headquarters and grep the logs. Incidentally, this would work even with DNSCurve deployed.
Anyone who would advocate for DANE in 2013 is looking at a situation where users assume that governments have compromised the PKI that drives the most important encryption on the Internet, and saying to themselves, "let's bake that problem into the network architecturally; let's make it so that the NSA doesn't even need to compromise a CA, because they'll own the global root of all CAs".
Regarding NSEC3: most people reading this thread don't know what it is, so I'll explain it really quickly and let them decide, because it it so obviously a stupid hack that I don't think I need to argue against it too much:
Just a couple years ago --- more than a decade after work on DNSSEC was started --- somebody realized that Bank of America would not in fact be OK with a DNS design where every single one of their hostnames, for both public and internal systems, was public. But that's a problem, because DNSSEC wants to authenticate negative responses; if there's no JABBERWOCKY.BANKOFAMERICA.COM, DNSSEC wants that cryptographically proven. But their design to do that breaks if there are nonpublic names, because DNSSEC chains the names together as a way to authenticate denial.
So here's what they came up with: domain names are hashed (crappily) as if for a 1997 Unix password file, and the authenticated denial messages refer to hash ranges instead of literal hostnames. Meaning you can only discover all of Bank of America's hostnames if you are as technologically sophisticated as a circa-1997 password cracker.
I don't know why you're talking about the NSA. And if you are, anyway, do you really think they can't ask Verisign for an arbitrary cert already? And won't the same tools that modern network programs use to protect against these attacks (certificate pinning, convergence, etc.) work equally well when applied to DNSSEC KSKs?
NSEC3 is good enough. I gave you a trivial way of acquiring jabberwocky.bankofamerica.com, even with DNSCurve deployed. If BOA wants network accessible services on a network accessible namespace to be private, they should make a zone cut at internal.bankofamerica.com and restrict access to the delegated NS (which can be the same machine). The easiest way to do this is to run a VPN, which they already do.
I am asserting that having a global key-value store, where namespace owners can sign their own entries and make delegations, is a valuable system to have in place. That is what DNSSEC is. Unless you can argue against that, you are simply beating on a straw man.
Why spend the money adopting DNSSEC if it's at best a marginal setback to Internet security?
The "trivial way of acquiring jabberwocky.bankofamerica.com" relies on somehow being in the same coffee shop as an employee who accesses the site using public DNS. Whereas DNSSEC just goes right ahead and publishes the information.
As for "making zone cuts" --- they haven't. Very few networks have. DNSSEC advocates just like to pretend that everyone has either architected their DNS zones they way they would, or that they'll all relabel all their hosts to fit that way.
I don't know why I should care about a "global key value store where namespace owners can sign their own entries and make delegations". We can have lots of those. Why use a crappy one bolted onto DNS?
It's not a setback at all. You can still use the existing CA system. In fact, you can just not set the secure bit and ignore its existence.
As for "making zone cuts" --- they haven't. Very few networks have. DNSSEC advocates just like to pretend that everyone has either architected their DNS zones they way they would, or that they'll all relabel all their hosts to fit that way.
Very few networks have ridiculous PHB requirements for public servers defined on public namespaces that are somehow slightly more difficult to find than normal (and once the cat / jabberwocky is out of the bag and published to a mailing list somewhere, gives no advantage whatsoever).
Those that do have reasonable options for satisfying said PHBs, first with NSEC3 and then with zone cuts and private networks (which actually does solve the problem, instead of just pretending to solve it).
I don't know why I should care about a "global key value store where namespace owners can sign their own entries and make delegations". We can have lots of those. Why use a crappy one bolted onto DNS?
What alternatives? To my knowledge, there is no credible alternative system to DNS. Why put up with a DNS system that is not end to end verified when you don't have to?
Comments
DNSSEC provides minimal value and adds significant overhead. We're better off the less it's deployed.
If you're like me, and wishing tptacek would elaborate, it turns out he has in the past. For example, this entertaining thread from three years ago:
https://news.ycombinator.com/item?id=1234567
Also, despite my earlier google queries about DNSSEC, everything I was reading was pretty dry. The magic phrase to google for is "DNSSEC sucks"--that gets you the interesting stuff.
I haven't digested it yet, but in those results, this looks pretty interesting from D. J. Bernstein: http://cr.yp.to/talks/2010.12.28/slides.pdf
More:
https://news.ycombinator.com/item?id=5571937
https://news.ycombinator.com/item?id=4071178
https://news.ycombinator.com/item?id=2932378
I really don't like DNSSEC. I think it's a bad design that will harm the Internet.
The a video of the talk those slides are from is online http://vimeo.com/18417770
Worth watching even if you don't care much about DNSSEC, Bernstein is a good speaker.
I don't understand why your criticism of DNSSEC focuses on TLS vs. DNSSEC.
DNS is a scalable global key-value store, and DNSSEC allows owners of namespaces to sign their own key pairs and delegate to sub-namespaces. If you can make the case that _that_ is not valuable, or how that is accomplished by other means, I am curious. But TLS vs. DNSSEC doesn't cut it.
Yes, DNSSEC/DANE can make TLS work better. It provides a straightforward way to pin an entire zone tree while allowing site owner modifications. Your example of Ghadaffi and Bit.ly is silly, because the status quo is that governments already have access to CA keys able to issue for any server. Restricting to a single zone can only improve that.
I don't know how you can claim NSEC3 is a grotesque hack without noting that it is equally grotesque to pretend that your DNS records are private. If I wanted to collect the BoA zone, I would setup recursive nameservers on the coffee shops' wifi within a quarter mile of their headquarters and grep the logs. Incidentally, this would work even with DNSCurve deployed.
Anyone who would advocate for DANE in 2013 is looking at a situation where users assume that governments have compromised the PKI that drives the most important encryption on the Internet, and saying to themselves, "let's bake that problem into the network architecturally; let's make it so that the NSA doesn't even need to compromise a CA, because they'll own the global root of all CAs".
Regarding NSEC3: most people reading this thread don't know what it is, so I'll explain it really quickly and let them decide, because it it so obviously a stupid hack that I don't think I need to argue against it too much:
Just a couple years ago --- more than a decade after work on DNSSEC was started --- somebody realized that Bank of America would not in fact be OK with a DNS design where every single one of their hostnames, for both public and internal systems, was public. But that's a problem, because DNSSEC wants to authenticate negative responses; if there's no JABBERWOCKY.BANKOFAMERICA.COM, DNSSEC wants that cryptographically proven. But their design to do that breaks if there are nonpublic names, because DNSSEC chains the names together as a way to authenticate denial.
So here's what they came up with: domain names are hashed (crappily) as if for a 1997 Unix password file, and the authenticated denial messages refer to hash ranges instead of literal hostnames. Meaning you can only discover all of Bank of America's hostnames if you are as technologically sophisticated as a circa-1997 password cracker.
You didn't actually respond to what I said.
I don't know why you're talking about the NSA. And if you are, anyway, do you really think they can't ask Verisign for an arbitrary cert already? And won't the same tools that modern network programs use to protect against these attacks (certificate pinning, convergence, etc.) work equally well when applied to DNSSEC KSKs?
NSEC3 is good enough. I gave you a trivial way of acquiring jabberwocky.bankofamerica.com, even with DNSCurve deployed. If BOA wants network accessible services on a network accessible namespace to be private, they should make a zone cut at internal.bankofamerica.com and restrict access to the delegated NS (which can be the same machine). The easiest way to do this is to run a VPN, which they already do.
I am asserting that having a global key-value store, where namespace owners can sign their own entries and make delegations, is a valuable system to have in place. That is what DNSSEC is. Unless you can argue against that, you are simply beating on a straw man.
Why spend the money adopting DNSSEC if it's at best a marginal setback to Internet security?
The "trivial way of acquiring jabberwocky.bankofamerica.com" relies on somehow being in the same coffee shop as an employee who accesses the site using public DNS. Whereas DNSSEC just goes right ahead and publishes the information.
As for "making zone cuts" --- they haven't. Very few networks have. DNSSEC advocates just like to pretend that everyone has either architected their DNS zones they way they would, or that they'll all relabel all their hosts to fit that way.
I don't know why I should care about a "global key value store where namespace owners can sign their own entries and make delegations". We can have lots of those. Why use a crappy one bolted onto DNS?
It's not a setback at all. You can still use the existing CA system. In fact, you can just not set the secure bit and ignore its existence.
Very few networks have ridiculous PHB requirements for public servers defined on public namespaces that are somehow slightly more difficult to find than normal (and once the cat / jabberwocky is out of the bag and published to a mailing list somewhere, gives no advantage whatsoever).
Those that do have reasonable options for satisfying said PHBs, first with NSEC3 and then with zone cuts and private networks (which actually does solve the problem, instead of just pretending to solve it).
What alternatives? To my knowledge, there is no credible alternative system to DNS. Why put up with a DNS system that is not end to end verified when you don't have to?