DNSSEC: Complexities and Considerations(blog.cloudflare.com)
blog.cloudflare.com
DNSSEC: Complexities and Considerations
http://blog.cloudflare.com/dnssec-complexities-and-considerations/
8 comments
Right, NEC3's 'solution' to obscure zones by signing hashes effectively just renames zones that probably come from some small collection ('www', 'ftp', 'ns', 'smtp', 'ilo') and not secure for the same reason hashing phone numbers is ineffective.
Arguments that administrators can choose names with large entropy would miss the point as it puts an undue burden on administrators and users to use 'bizarre' names.
Further arguments that you can brute force names using normal ol' A records also miss the point. The difference is online versus offline enumeration.
> it's based on RSA PKCS1v15
Eww. I had no idea. Next you'll tell me the root key's public exponent is 3. Gross.
> If your most important adversary is GCHQ and NSA, then the Internet is far more threatened by the deployment of DNSSEC than it is by DNSSEC's absence.
Not sure it makes too much of a difference in this case... you can't trust non-signed DNS records if your adversary is NSA/GCHQ, and you can't trust typical PKI to bail you out either.
Arguments that administrators can choose names with large entropy would miss the point as it puts an undue burden on administrators and users to use 'bizarre' names.
Further arguments that you can brute force names using normal ol' A records also miss the point. The difference is online versus offline enumeration.
> it's based on RSA PKCS1v15
Eww. I had no idea. Next you'll tell me the root key's public exponent is 3. Gross.
> If your most important adversary is GCHQ and NSA, then the Internet is far more threatened by the deployment of DNSSEC than it is by DNSSEC's absence.
Not sure it makes too much of a difference in this case... you can't trust non-signed DNS records if your adversary is NSA/GCHQ, and you can't trust typical PKI to bail you out either.
Migrating from a fatally flawed PKI to a PKI that is fundamentally flawed practically by design is a big problem.
I used to be a DNSSEC fan. Moxie changed my mind with one phrase:
"I don't trust the players." He turned out to be justified in that assessment. The players you have to trust are not only the government that runs your TLD, but the registrars who are now your security lynchpins.
The main upside of DNSSEC is you only have to trust your parents, while in something like the CA system today you basically have to trust every CA in the system. (As well as your registrar and email provider as long as domain validated certs are just as trusted as every other cert.)
The other upside is that the system is designed for caching. NSEC exists so you can safely cache NX records. This leads to a lot of crappy design choices, but also the worlds most scalable, distributed key value store that would become much more trustworthy with DNSSEC. This is great in theory, but doesn't solve any practical problems we have in the real world right now.
Public key pinning is a much better next step than DNSSEC is. It gives us the ability to only trust one registrar who we hopefully choose with security in mind.
I will quibble with a few of your points. NSEC3 is not your only option, you can use RFC 4470 minimal NSEC records with your key online if you wish. DNSSEC provides options out the wazoo, a function of design by committee over many years. This is also true of signature and cipher algorithms, where the situation is improving over time as agility is built into the system. They may provide some reasons to hate the situation right now, but eminently fixable.
Also, people might not understand that root key signing keys (long lived keys like we're used to in TLS) are currently 2048 bit RSA, and zone signing keys that are rapidly rolled over (~90 days) are 1024 bit RSA. This means the strength needed to resist attack is much reduced from the key lengths/validity periods people are used to thinking about.
"I don't trust the players." He turned out to be justified in that assessment. The players you have to trust are not only the government that runs your TLD, but the registrars who are now your security lynchpins.
The main upside of DNSSEC is you only have to trust your parents, while in something like the CA system today you basically have to trust every CA in the system. (As well as your registrar and email provider as long as domain validated certs are just as trusted as every other cert.)
The other upside is that the system is designed for caching. NSEC exists so you can safely cache NX records. This leads to a lot of crappy design choices, but also the worlds most scalable, distributed key value store that would become much more trustworthy with DNSSEC. This is great in theory, but doesn't solve any practical problems we have in the real world right now.
Public key pinning is a much better next step than DNSSEC is. It gives us the ability to only trust one registrar who we hopefully choose with security in mind.
I will quibble with a few of your points. NSEC3 is not your only option, you can use RFC 4470 minimal NSEC records with your key online if you wish. DNSSEC provides options out the wazoo, a function of design by committee over many years. This is also true of signature and cipher algorithms, where the situation is improving over time as agility is built into the system. They may provide some reasons to hate the situation right now, but eminently fixable.
Also, people might not understand that root key signing keys (long lived keys like we're used to in TLS) are currently 2048 bit RSA, and zone signing keys that are rapidly rolled over (~90 days) are 1024 bit RSA. This means the strength needed to resist attack is much reduced from the key lengths/validity periods people are used to thinking about.
We're in the middle of a 4 year streak of findings stemming from archaic 1990s constructions embedded in TLS, from BEAST to CRIME to Lucky 13 to RC4 to POODLE.
It is unconscionable that the IETF would consider deploying a protocol whose modal deployment configuration will be PKCS1v15 RSA.
The I-D's with ECC options don't matter, any more than they mattered for the last 5 years with TLS 1.2. The protocol isn't even fucking deployed yet --- what we have today are pilot deployments. How could they possibly be fielding PKCS1v15 RSA in 2014?
It is unconscionable that the IETF would consider deploying a protocol whose modal deployment configuration will be PKCS1v15 RSA.
The I-D's with ECC options don't matter, any more than they mattered for the last 5 years with TLS 1.2. The protocol isn't even fucking deployed yet --- what we have today are pilot deployments. How could they possibly be fielding PKCS1v15 RSA in 2014?
[deleted]
Design by committee generally leads to poor results. A much better approach is the competition method, where e.g. the public is asked for proposals to secure DNS as in the AES, eSTREAM, PHC, and CAESAR competitions.
DNSSEC was not "design by committee" -- it was "design by multiple committees, all stuck in the 1990s." And this is what we get.
Personally I say: DNSCurve > DNS > DNSSEC. I would support a DNS security competition, even if DNSCurve (which I've deployed) were not selected. DNSSEC wouldn't stand a chance in a public competition.
DNSSEC was not "design by committee" -- it was "design by multiple committees, all stuck in the 1990s." And this is what we get.
Personally I say: DNSCurve > DNS > DNSSEC. I would support a DNS security competition, even if DNSCurve (which I've deployed) were not selected. DNSSEC wouldn't stand a chance in a public competition.
I've been pretty down on DNSSEC due to the "baroque" nature of the whole thing (which this blog post shows); also, giving extra power to country-level ccTLDs vs. the slightly-more-independent SSL/x509 CAs.
However, DANE makes DNSSEC make sense in some cases, especially when you start using it for things other than web traffic. DNSSEC/DANE for STARTTLS SMTP would be a good improvement over the "no cert checking at all, and even cert failures are ignored" model today.
However, DANE makes DNSSEC make sense in some cases, especially when you start using it for things other than web traffic. DNSSEC/DANE for STARTTLS SMTP would be a good improvement over the "no cert checking at all, and even cert failures are ignored" model today.
* DNSSEC was designed to assume that keys would be kept offline, because online signatures were thought not to be performant enough†.
* DNSSEC was designed to provide authenticated denial, because it was designed during a time when support protocol maintainers believed they needed built-in countermeasures for high-level DOS attacks.
The assumption behind these design goals are both dubious, but particularly noxious when combined.
There is more wrong with DNSSEC than NSEC3, for whatever it's worth; for instance, start with the fact that it's based on RSA PKCS1v15; until recently (last time I checked, within the last 18 months), the root of the hierarchy used 1024 bit keys.
These are, of course, technical issues. There's a fundamental Internet design problem with DNSSEC, too, which is that the roots of the DNS hierarchy are overwhelmingly controlled by world governments. DNSSEC is, at bottom, a centralized PKI dominated by the US Government.
But don't worry, this is only what DNS advocates want you to store your TLS keys in.
The entire security model for the Internet has been tuned for the last 15 years not to assume the DNS was secure. DNSSEC does not in any meaningful way exist today. If your most important adversary is the kind of online criminal that might employ DNS redirection to steal your credit cards, the risk/reward for DNSSEC might arguably make sense (I think you'd lose that argument, though). If your most important adversary is GCHQ and NSA, then the Internet is far more threatened by the deployment of DNSSEC than it is by DNSSEC's absence.
† (this believe has since been retconned into a belief that keeping keys online is "insecure", which is Rosencrantz and Guildernstern-style amusing given that DNSSEC controls only hostname mappings and that virtually every other system that protects content does keep keys online)