

DNSSEC: Complexities and Considerations - fcambus
http://blog.cloudflare.com/dnssec-complexities-and-considerations/

======
tptacek
DNSSEC suffers from the zone exposure problem because its design was, for many
intents and purposes, nailed down in the 1990s based on assumptions about
cryptography from the 1990s. Specifically:

* 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)_

~~~
xnull
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.

~~~
tptacek
Migrating from a fatally flawed PKI to a PKI that is fundamentally flawed
practically by design is a big problem.

------
Panino
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.

------
rdl
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.

