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
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?