
Against DNSSEC - tptacek
http://sockpuppet.org/blog/2015/01/15/against-dnssec/
======
colmmacc
There are at least two more arguments against DNSSEC:

1) DNSSEC does materially make DDOS reflection attacks worse. djb has gone on
about this at length, so I won't.

2) DNSSEC also degrades a DNS server's ability to respond to requests. A
regular non-DNSSEC DNS server can look up responses in O(1) time; see djb's
TinyDNS for an example (it uses a CDB hash table to do it). A DNSSEC server
must either use an ordered index to find "nearest match" for NSEC(3) ... and
hence is O(log N), or it must sign the response on demand (which is against
DNSSEC religion) and takes something like quadratic time.

It is a meaningful increase in both the computational and space complexities
of serving a core infrastructural protocol - but for no meaningful benefit.

~~~
leni536
Well I'm sure that plain DNS look up responses are faster but I have been
tought that that the difference between O(1) and O(log N) is really just
theoretical and in practice the constant factor is typically more important.
log N grows really slowly in the function of N.

~~~
geocar
O-notation lacks utility. It isn't sufficient for a thorough analysis of the
space/time complexity of algorithms, and profiling is much easier anyway.

In this case: The constant coefficient in a DNS lookup is very small, whilst
the constant coefficients in a DNSSEC response are very big.

------
dsacco
I agree with everything Thomas has said here, but I also think that it might
be a good idea to explain why proponents believe DNSSEC is a good idea for
those who don't have a good handle on it.

1\. DNS is vulnerable to man in the middle attack. Any authority with access
to a root server or another router in the DNS resolution chain can tell a
computer that a web page goes anywhere they want. This actually happens - for
example, Turkey tried to go this with Twitter, and redirected Twitter's domain
name to a government IP address instead for anyone within the country.

2\. There is a dangerous vulnerability called DNS cache poisoning where UDP
packets can be used to manipulate DNS servers to incorrectly respond when
queried for a domain's IP address until their cache expires. This attack was
described in 2008 by Dan Kaminsky, and on the whole, a methodology of
preventing this sort of vulnerability would be good enough motivation for
repairing the failings of present-day DNS.

The motivation is great, but DNSSEC is largely the wrong tool for the job -
it's a blunt instrument with no support for nuance and it will make DNS
harder. What Thomas explains in greater technical detail is that DNSSEC is a
move towards even further internet centralization that will make
implementation more difficult without really solving the principal issues.

~~~
colmmacc
It's worth keeping in mind that the Turkish government hi-jacked DNS
resolvers; as-deployed DNSSEC would in no way have helped.

The 2008 attack was not novel and was described by DJB about 7 years prior to
Kaminsky, and DJB's utilities included a mitigation: randomized source ports.
At present there is an equivalent vulnerability: UDP/IP fragments can be
spoofed in such a way that poison records can be injected to resolvers. It is
possible to mitigate this, but many DNSSEC proponents - including the Bind
maintainers - refuse to consider mitigations because they feel that people
should be moving to DNSSEC instead. It bears repeating that as-deployed;
DNSSEC doesn't help protect against cache poisoning towards stubs - only
towards caching resolvers.

~~~
tptacek
DNSSEC was also the reason why source ports weren't randomized, and thus the
reason that Kaminsky's attack was briefly so viable. Somewhere there's a NANOG
post with the BIND maintainers talking about the "scoreboarding resolver"
they'd implemented but wouldn't release, because (even back in 1997) the real
answer was DNSSEC.

I'm not sure I agree about the novelty of Kaminsky's attack. Ruefully: I
remember arguing with him about that on Twitter, him getting me on the phone
to explain how his attack refined the older cache poisoning attacks, me
conceding it, and then bad stuff happening a few months later.

~~~
sarciszewski
> and then bad stuff happening a few months later.

Are you referring to
[http://www.gonullyourself.org/ezines/ZF0/zf0%205.txt](http://www.gonullyourself.org/ezines/ZF0/zf0%205.txt)
perchance?

~~~
tptacek
No.

------
axaxs
I understand DNSSEC may not be the perfect solution, but many arguments are
misguided. Worse yet, no real solution has been posed in its stead that works
perfectly. But here I go again. In fairness, there are some valid arguments.
I'm cherry picking pieces I find questionable.

DNSSEC is a Government-Controlled PKI - DANE is not DNSSEC. Why conflate the
two?

DNSSEC is Cryptographically Weak - Wait, what? That's like saying openssl is
cryptographically weak, since it allows you to create weak keys. You can use
ECDSA with DNSSEC. Minimal research would have revealed that.

DNSSEC is Expensive To Adopt - It is up to the software to decide how to
handle failure cases. Software with security in mind should do the proper
checks. Others should display warnings. Others should probably just accept the
answer.

DNSSEC is Expensive To Deploy - What? DNSSEC is braindead simple to deploy. It
literally takes a handful of minutes.

DNSSEC is Incomplete - Unclear...not positive how DNSSEC relates to browser
implementation.

DNSSEC is Unsafe - I'll possibly give you this one, but stand by that you
shouldn't hide in plain sight. That is, why put 'hidden' records in a public
zone?

DNSSEC doesn’t have to happen. Don’t support it. - DNSSEC has already
happened. People ask for it. However, largely, I support the argument. Start a
working group, propose a better alternative, and replace it. I'm all for that,
believe it or not.

~~~
tptacek
There is a real alternative solution, and it has the virtue of being
exceptionally simple: do nothing. The DNS doesn't need to be secured, just
like raw IP isn't, nor every individual BGP4 update.

DANE (using DNS as an alternative to TLS CAs) is the primary real-world use
case for DNSSEC.

No site in the world is secured purely using ECC DNSSEC, because the roots and
TLDs rely on RSA. Moreover: find the most popular site that uses ECC DNSSEC
and report back what it is. (It'll be tricky, because very few of the most
popular sites use DNSSEC at all). And, of course, the ECC variants DNSSEC uses
are already outmoded. Which is why I was careful to refer to modern
deterministic Edwards-curve signature schemes. Also: did you really look at
the links in that post and think it lacked even "minimal research"?

I don't see any other arguments in this response, but you can call me out if I
missed any.

~~~
axaxs
DANE is not DNSSEC, and was not and is not the motivation behind it. That
thought is incorrect.

As for algorithms, you're insulting DNSSEC as it's been implemented, not as a
protocol. DNSSEC reserves purposely up to 255 slots for algorithms, and has
added them as it's evolved. But claiming it depends on RSA and doesn't support
modern eliptical curve schemes is at worst wholly false, at best half false
depending on the definition of modern.

~~~
tptacek
All I can say is that I've read, I believe, every dnsext and namedroppers post
and the archives of the old mailing lists from the 1990s, when DNSSEC was a
government funded project of my then employer, for whom I was busy writing DNS
security testing tools, and I believe you're wrong: DANE is the motivating use
case for DNSSEC.

It's a pretty weird rhetorical spot to put yourself in, by the way. Without
DANE as a motivation for deployment, there is _no_ reason to deploy DNSSEC.
DNSSEC can't provide end-to-end security, and TLS and SSH already authenticate
themselves without DNSSEC.

I don't know what your second paragraph means. You can see what I'm referring
to empirically by playing with DNSviz. Like I said: go find the largest DNSSEC
site that uses ECC records. Then, for fun, and not counting the TLDs
themselves (sigh), the largest that use RSA-1024.

------
IgorPartola
So just to be clear, the thesis here is that we should not secure DNS in any
way, correct? Or is part 2, in a series of articles going to detail a
different solution?

In other words, is the objection to DNSSEC the idea, or the implementation?

Lastly, what is our best hope for getting rid of CA's?

~~~
tptacek
The thesis here is in fact that we should not secure DNS in any way, just like
we don't secure raw IP and won't for the foreseeable future secure BGP4. We
instead do what we've done for 20+ years: assume the network is untrustworthy
(because it is, with or without DNSSEC) and build security on top.

~~~
IgorPartola
Thanks for clarifying! I have followed many of the discussions in which you
participated talking about this issue, but this is the most concise way this
has been put.

If I may suggest something, the article talks a lot about the implementation
flaws in DNSSEC, giving the impression that if only it was designed better, or
even redesigned, that we could actually have a secure DNS.

------
zdw
DNSSEC is probably OK if all you use it for is within an organization for your
own stuff (ie, with your corporate root CA, for your corporate domains only,
where you control for and vouch for every node connected), and then using it
to enhance other things like distributing SSH keys through SSHFP (again,
totally internally, not internet facing).

But everything else said here I totally agree with - if you don't control the
root, you don't control a whole lot of anything.

If you want something that hides the contents of DNS packets in transit,
DNSCurve at least does that, and is relatively easy to deploy - the current
best server appears to be the curvedns in the freebsd ports (updated to use
libsodium, etc.):
[https://svnweb.freebsd.org/ports/head/dns/curvedns/](https://svnweb.freebsd.org/ports/head/dns/curvedns/)

~~~
marcosdumay
> if you don't control the root, you don't control a whole lot of anything.

What's of course valid for TLS too. Do you suggest people use HTTPS?

------
efesak
> DNSSEC is Expensive To Adopt/Deploy

I live in .cz domain and almost every registrar there have DNSSEC in one click
(without changing price) - adoption here is 40%! - see
[https://stats.nic.cz/stats/domains_by_dnssec/](https://stats.nic.cz/stats/domains_by_dnssec/)
and I am not experiencing any mentioned problems at all

Maybe DNSSEC is not best DNS proto in the world, but these arguments are not
entirely based on facts.

~~~
tptacek
This is like saying "TLS is easy if you just let GoDaddy manage your keys for
you".

~~~
xorcist
Incorrect. You don't have to let CZ.NIC manage your keys for you.

~~~
xenophonf
That's not what he's saying. DNSSEC is a pain in the ass to operate on your
own, and that's with guides like [http://users.isc.org/~jreed/dnssec-
guide/dnssec-guide.html](http://users.isc.org/~jreed/dnssec-guide/dnssec-
guide.html) (which is itself relatively new). BIND, at least, has a lot of bad
defaults (e.g., NSEC), and the docs make poor recommendations about algorithms
and key sizes (SHA-1? 1024-bit RSA keys? and what's this about RSA being
depreciated after September 2015?)---even NIST's guidelines make stronger
recommendations than that
([http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-13...](http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf),
and that still has Dual EC DRBG on the books). Furthermore, ISC's guide
downplays the importance of DNSSEC on private networks, which is probably the
most important (in terms of opsec) and most difficult (in terms of complexity)
place to implement it.

DNSSEC doesn't offer any privacy guarantees, either, so at this point DNSSEC
doesn't really do much for me.

~~~
xorcist
That's not what I am saying at all.

I am saying "almost every registrar [in .cz] have DNSSEC in one click (without
changing price)" is nothing like "letting GoDaddy manage your keys for you".

The first is a matter of cost. The second a matter of convenience.

It's not at all like letting a third party manage your keys in any reasonable
way to interpret it.

------
blfr
_Securing those DNS lookups therefore enables no meaningful security._

When you're reasonably sure that the DNS response you're seeing is actually
what the zone owner meant it to be, you can have records for SSL certificates
(DANE, mentioned later), or GPG keys for users with email in that domain, all
kinds of things which were not previously possible. Each of those may or may
not be a good idea but it clearly enables meaningful uses.

 _DNSSEC is a Government-Controlled PKI_

Sure. But once you're willing and able to forge registry information about a
domain, you can also usually get a valid (DV) certificate for it. Assuming you
don't control a CA to begin with. So at least we're being honest with
ourselves and stop paying for the security we don't get.

And DNSSEC doesn't get in the way of any replacements, does it? You can sign
the certificate with your personal key. Or you can use some sort of
convergence mechanism to see if you're seeing the same public key as everyone
else.

 _Authenticated denial. Offline signers. Secret hostnames. Pick two._

The first two, right? (Secret hostnames?)

Articles like this (whole lists of criticisms) sound lawyery and unconvincing
to me. I can't tell which ones are the meat and which are garnish. Not that a
committee design cannot be flawed in multiple ways (death from 1000 cuts
style) but this feels as if the author didn't like the idea first, perhaps for
a perfectly valid reason, and came up with a bunch of additional reasons
later.

Full disclosure: I signed one of my zones and I run validating resolvers for
my private needs (unbound, both on servers and my home network). Nothing blew
up. Yet.

~~~
tptacek
Governments today have too much control over Internet crypto keys. I am
baffled by arguments that suggest it might be a good thing to just give up and
give them total control over them.

~~~
ploxiln
Today many many governments can create TLS certs for _any_ website domain.

With DNSSEC, only the USA can, and other governments can only create TLS certs
for a small and distinct subset of website domains. That's better.

(It would be even better if dns resolvers included certs for all TLDs they
knew about, and did not rely on the root keys for those TLDs. Just like
pinning TLS certs. Then, you can choose a TLD run by an organization you
trust, and even the US won't be able to forge your certs.)

~~~
chopin
> With DNSSEC, only the USA can, and other governments can only create TLS
> certs for a small and distinct subset of website domains. That's better.

I fail to see how that is better.

~~~
eltrai
Less organisation that can forge = less weak-points = better security

------
danyork
Thomas - I'm still looking for the walk-through of how you see the attacks by
a government against DNSSEC. I don't see them!

And to your repeated refrain both in your post and here on HN that "DNSSEC has
virtually no real-world deployment", I would again refer you to various DNSSEC
statistics sites that do indeed show a good amount of deployment happening in
different parts of the world.

Here's a list of those sites:
[http://www.internetsociety.org/deploy360/dnssec/statistics/](http://www.internetsociety.org/deploy360/dnssec/statistics/)

I know you wish it were NOT happening, but the reality is that DNSSEC
deployment _is_ going on... and many of us see it as a way to provide another
solid layer of security on the Internet.

Yes, it's always great to be exploring other alternatives, too. My personal
interest is in "securing the DNS"... and right now DNSSEC is to me the best
tool we have going _today_. If we can develop other tools over time that are
even better, that will be outstanding. Meanwhile, I want to see what we have
today get better deployed.

~~~
tptacek
I keep seeing a claim that something like 10% of DNS requests are signed with
DNSSEC, but that's an awfully hard number to square with the top sites on the
Internet, virtually none of whom are DNSSEC-signed. Reconcile for us, please?

~~~
nmc
_" signed with DNSSEC"_ is an ambiguous statement. You need to take into
account that, while nameservers may enable DNSSEC, resolvers may:

(a) validate (include the AD bit) but strip the RRSIGs (i.e. regular DNSSEC
resolver)

(b) omit the AD bit but include the RRSIGs (i.e. you have to validate
yourself)

(c) omit the AD bit and omit the RRSIGs (i.e. regular non-DNSSEC resolver)

(d) validate (i.e. include the AD bit) and include the RRSIGs (i.e. alleluia!)

My own study [0] (using the Atlas network [1]) found 30% of resolvers doing
(a), and 65% doing (b), including some overlap. There are people way more
qualified than me doing this kind of stuff, namely APNIC's Geoff Huston, see
[2] for instance.

[0]
[https://www.os3.nl/_media/2013-2014/courses/rp2/p14_report.p...](https://www.os3.nl/_media/2013-2014/courses/rp2/p14_report.pdf)

[1] [https://atlas.ripe.net](https://atlas.ripe.net)

[2] [http://www.potaroo.net/presentations/2014-06-03-dns-
measurem...](http://www.potaroo.net/presentations/2014-06-03-dns-
measurements.pdf)

------
worklogin
How much more centralized does DNSSEC make the Internet? It's already bad
enough that people are calling for mandatory TLS for all websites (though with
free certs from the EFF/mozilla that will be a bit less painful) but if I want
to have my own DNS root, or play by my own rules on the net, will running my
own infrastructure be harder with DNSSEC?

~~~
tptacek
Yes. If a CA egregiously misbehaves today, Google can kneecap it with an
update to Chrome, and end-users can remove it from their configuration
entirely (this should be easier to do, by the way, and there's no technical
reason it can't be).

If the signers for .LY or .COM misbehave, nobody has any solid recourse.
.COM's role in the post-DANE certificate hierarchy is _baked into the fabric
of the Internet_.

DNSSEC represents a massive move _towards_ centralization of Internet trust,
which is a baffling thing to get behind in 2015.

~~~
wglb
There are in fact organizations that scrupulously audit the certificates in
all browsers/cert stores in their organization. One I know of is etsy.

~~~
wglb
Here is a reference well worth reading about how they approach security:
[http://www.slideshare.net/zanelackey/attackdriven-
defense](http://www.slideshare.net/zanelackey/attackdriven-defense)

------
peterwwillis
You know, it's possible to simply lift the guts out of the TLS protocol and
wrap them around a directory service, or to take the architecture of DNSSEC
and kludge it into TLS. Basically we can keep TLS's good points and support an
_alternative_ to CAs within the protocol itself. All a service provider'd have
to do is pick one or both to support, and advertise in the protocol what
combination they use. That'd be a fun weekend project.

------
ta78787
Non-expert here, why are secret hostnames important? Aren't the machines
either reachable by IP Address or not regardless of whether the hostname is
known or not?

~~~
wmf
I guess it's a form of defense in depth. Hostnames often contain information
about the role of a server that wouldn't be obvious from an IP scan.

------
Perseids
While DNSSEC certainly deserves a lot of criticism, I think some of the points
are unfair.

> Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled
> BIT.LY’s TLS keys.

(DNSSEC's, and thus) DANE's security can break down at every parent DNS zone.
For bit.ly the parent zones are the .ly top level domain and the root zone.
Each of them (but only these two) can forge valid DNSSEC records. With the
current X.509 certificate infrastructure there are more than a hundred root
CAs who can issue malicious certificates for use with TLS. Even though I
certainly dislike the centralized nature of DNSSEC, it is hard to argue that
reducing the attack surface from over a hundred institutions to two or three
doesn't constitute a marked improvement. Specifically, domains like tumblr.com
whose domain path is completely US hosted will no longer have to worry about
"obscure" foreign CAs like "Unizeto Certum".

> In fact, it does nothing for any of the “last mile” of DNS lookups: the link
> between software and DNS servers. It’s a server-to-server protocol.

DNSSEC is decidedly not a server-to-server protocol. The signatures are
created offline and can be verified by any party, even when they come out of a
cache. In contrast, DNSCurve _is_ a server-to-server protocol, which only
secures the transport layer, but not the data itself. The post refers to the
aspect, that stub resolvers (those software parts of your OS that look up the
query at your ISP caching DNS server) where not envisioned by the designers of
DNSSEC to verify the DNSSEC entries themselves. Nonetheless, there is nothing
that hinders them from doing so and I would expect that feature to be included
once DNSSEC is spread enough to justify the effort. In fact, you can already
check how this would work using the dig request `dig @8.8.8.8 +dnssec
example.com` which replies with the A record and the signature on the A record
(you still need to get and verify the zone key of example.com though).

> DNSSEC changes all of that. It adds two new failure cases: the requestor
> could be (but probably isn’t) under attack, or everything is fine with the
> name except that its configuration has expired. Virtually no network
> software is equipped to handle those cases. Trouble is, software must handle
> those cases.

I'm curious about why software would have to handle these cases. For the end-
user a binary "lookup went well, here is the result" / "there were some errors
during the lookup, sorry I can't or won't give you a result" should be totally
sufficient. Firefox should not confuse the user with detailed difference
between "I can't verify this record, even though the parent zone says it is
DNSSEC enabled" and "I can't resolve the name at all", so why does Firefox
need this information?

~~~
tptacek
Look at the code in Firefox that handles certificate failures, presents user
interface to end users to resolve the ambiguity, and then completes the
operation once that happens. Then look at the sample code I linked to. The
code I have there is a decent approximation of "idiomatic". The code I'm
referring to in browsers is larger by a factor of, what, 100? 1000?

Browsers and operating systems aren't going to add full DNSSEC resolving
caches. They're going to use stub resolvers and delegate this problem to "DNS
servers" (caches), like they always did. DNSSEC does not protect the last
mile. You can dodge this point by redefining the concept of "last mile", but
that's not a persuasive argument.

The US NSA controls both the CA hierarchy and .COM. It is amusing to see
people try to rescue DANE from criticism by evoking the CA system to protect
it.

~~~
blumentopf
> Browsers and operating systems aren't going to add full DNSSEC resolving
> caches.

Actually they already did. OS X for instance has this baked into
mDNSResponder.

~~~
tptacek
Fire up a terminal, run "tcpdump -s0 -i en0 udp", open Safari, resolve
"www.enteract.com", and tell me if you see a full recursive DNS lookup
happening, or if instead you see Safari's stub resolver asking the DHCP-
configured DNS cache server for help over the insecure Internet.

~~~
blumentopf
mDNSResponder supports DNSSEC validation, please look at the source code:

[http://opensource.apple.com/source/mDNSResponder/mDNSRespond...](http://opensource.apple.com/source/mDNSResponder/mDNSResponder-522.92.1/mDNSMacOSX/DNSSECSupport.c)

~~~
tedunangst
That doesn't really respond to the point. Does Safari use DNSSEC or not?

~~~
blumentopf
Of course it does, Safari uses the resolver provided by OS X, which is
mDNSResponder. (It superseded the stub resolver in libSystem.dylib starting
with 10.6.)

~~~
sffho
You are mistaken.
[https://news.ycombinator.com/item?id=8896092](https://news.ycombinator.com/item?id=8896092)

------
cdjk
I've never understood the criticism that DNSSEC places control of TLS keys
with governments - it seems like they already have that control. For example,
Libya could change the dns records for bit.ly and get a certificate. I suppose
an EV certificate with offline verification might help that, but you could use
those with DANE, but DANE doesn't seem any worse than domain or email
validated certificates.

~~~
tptacek
They can do that because of domain-validated certificates, and they can do
that after the DNS is secured.

~~~
cpach
And the CA that issues the cert will be flamed and possibly removed from
Chrome/Firefox.

(Edit: If they are caught.)

~~~
cdjk
Why would they be removed? If the CA correctly follows all of their procedures
and approves a domain-validated cert, why punish them for approving what is a
legitimate request?

If the CA is coerced into issuing a cert, however, I agree with you.

~~~
cpach
You’re right. I misunderstood the scenario we were discussing.

------
cs02rm0
_There are better DNS security proposals circulating already._

Tease.

~~~
wglb
Perhaps he is referring to [http://dnscurve.org/](http://dnscurve.org/)

~~~
xorcist
DNScurve solves a different problem. It does not implement offline signing. It
is not something you could trust your cryptographic keys with.

------
xorcist
These are just the same old arguments all over again.

1\. DNSSEC is unnecessary, we have SSL.

Do you really want to argue that the CA PKI infrastructure is working? Placing
your trust in your top domain solves 99.5% of the problem, roughly
(considering there is about 500 CAs that you trust right now, that is not a
made up number).

2\. DNSSEC is a government-controlled PKI.

No, it's not. It is ICANN-controlled, which is under government mandate but
not government control. You already trust ICANN for the root zone, and they
have so far stayed out of politics, and has so far never meddled with domains
even when the US administration wants them shut down. Because if they did, the
Internet would route around them in a heartbeat.

This is actually one thing that DNSSEC did absolutely correct. If you want a
cryptographic assurance that a domain belongs to an owner, who better to make
the assertion than the TLD responsible for delegating it? Sure, if you get a
Libyan domain, you have to trust the Libyan TLD to sign it. But they are
already trusted to delegate it! They run the whois. If they decide to transfer
the ownership to Ghaddafi himself, there is absolutely nothing you can do
about it. If this is a problem for you, don't get a Libyan domain name.

3\. DNSSEC is insecure.

It's ugly, but it's not insecure in any practical way. It could be a lot more
modern, but it is in no way worse than SSL (see 1 above).

4\. DNSSEC is expensive.

It is already deployed. You are already paying the price for this, whatever it
was.

5\. DNSSEC is hard.

It adds complexity to your operations, but your tools already supports it and
it's included in courses already. No competing standard is.

6\. DNSSEC makes for DDoS.

That wasn't actually included in the list, but this one is true. DNS is a DDoS
vector, and DNSSEC strengthens it. That should be addressed. Better deployment
of filters would do much to improve the situation.

7\. DNSSEC allows for enumration of zones.

Also not included in the list. Yes, this is a real issue you need to be aware
of. Don't store private data in public zones. Use split zones for this.

All technical decisions is a matter of pros and cons. Pro is that it builds on
a proven infrastructure and is already deployed in most of the world. You
could absolutely build a modern standard, but these things take at least ten
years to roll out. Start today and build the successor to DNSSEC!

But remember that DNSSEC did get a few important things right: Assurance
follows delegation. Your DNS operator does not have your key. It protects
against negative answers. Make sure your successor inherits those.

~~~
tptacek
First, I'd be a little happier if you didn't misquote me for the convenience
of your comment. These _weren 't_ my subheds. You've rewritten some of them,
condensed others, added one, and misread another, which lead you to suggest
that I hadn't "allowed for enumeration of zones" when in fact there's a whole
subhed dedicated to it. You could just clarify at the top of your comments
that your numbered list is your own, not mine. I'd then strike this part of my
comment.

Now then:

1\. I do not argue that the CA PKI infrastructure is working. In fact, I state
explicitly that it is not. The problem is that DANE's replacement for the TLS
PKI is _controlled by world governments_. At a broader level, the problem is
that centralized PKIs don't work against nation-state adversaries. The
solution for the TLS CA problem is (a) a race to the bottom for CA pricing,
led hopefully by EFF, (b) widespread deployment of public key pinning, which
serves both to thwart CA attacks and to create a global surveillance system
against them, and (c) the eventual deployment of alternate opt-in TLS CA
hierarchies, such that users could for instance subscribe to a hypothetical
EFF CA hierarchy. DNSSEC accomplishes none of this.

2\. Yes, DNSSEC is a government-controlled PKI. Your whole argument here is
that if governments abused it, the Internet would "route around it". You can't
make that argument without conceding my point.

3\. I didn't write "DNSSEC is insecure" (though I think it is). I wrote that
it's cryptographically weak, which it is: it's PKCS1v15 RSA-1024. Crawl
signatures back to the roots: you'll see RSA-1024 all the way at the top of
the hierarchy. TLS has already deployed forward-secure ECC cryptography and
will by the middle of this year see widespread deployment of Curve25519 ECDH
and Ed25519 deterministic signatures. DNSSEC simply will not: it will be
RSA-1024 for the foreseeable future.

4\. "DNSSEC is expensive" is not a subhed in my post. "DNSSEC is expensive to
adopt" was, and it is: virtually no networking software currently handles soft
failures from lookups, which are a universal shared experience among HTTPS
users, and will occur just as frequently with DNSSEC (should it ever be
deployed). "DNSSEC is expensive to deploy" is another point I made, which is
also true: of the top 50 Alexa sites, why not go look how many are DNSSEC-
signed?

5\. "DNSSEC is hard" isn't something I wrote at all, so I don't know how to
respond to it.

6\. "DNSSEC makes for DDoS" is something I think is probably true, but also an
argument I wasn't willing to go to bat for, because amplification attacks
using ANY queries against normal DNS also work. But sure, if you want to add
fuel to the fire.

7\. "DNSSEC allows for enumeration of zones" is captured under "DNSSEC is
unsafe" in my post. If you answer to this is "don't use DNSSEC for important
zones", then we agree, modulo that I think you shouldn't use it at all.

~~~
sarciszewski
> a race to the bottom for CA pricing, led hopefully by EFF

Also Startcom. [https://startssl.com](https://startssl.com) (free TLS certs,
each good for one subdomain + your base domain, for one year)

~~~
__david__
Startcom is great (I use it for a bunch of domains), but there are some
caveats:

* They are only free for personal, non-commercial use. You can't (contractually) use them for your startup.

* They are free to acquire, but they charge to revoke them. So don't lose your key (even accidentally, via something like heartbleed).

* Their roots are not in the Windows XP base install. They _are_ included in an optional update, but my experience with a web site that had old machines in its demographics showed that practically no one had it installed. Given that XP is no longer supported by Microsoft, this point is getting less and less relevant as the days go by.

~~~
yuhong
I think even WinXP had auto root update by default, and even Win7 don't have
the StartCom root installed by default.

------
ctz
I think the internet would benefit from more competition in protocols,
especially those to do with security, and especially those that have
historically done a bad job (TLS, DNSSEC, PKIX).

These are obviously hard to design, with a bunch of trade-offs and decisions
to make along the way. I'd argue that this makes practical research and
competition more important, not less.

------
richardwhiuk
"Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled
BIT.LY’s TLS keys."

No he would have had their TLS public key, assuming they were deploying DANE,
which he could have got by going to their website.

~~~
tptacek
I think you're a little unclear on the concept here. The problem isn't that
Libya gains the ability to _read_ the TLS keys.

~~~
richardwhiuk
Since Libya can't write a valid certificate to DNS, the ability to make
changes doesn't help them. At worst, they might be able to make browsers
reject the certificate (as the one served by the server won't match the one in
DNS, or the one served by the server and in DNS (if your A records and DNS key
gets changed) isn't signed by a CA), but they can already do that. If you
don't trust your DNS Zone, you can already be trivially taken offline by them
deleting your DNS records.

Once DANEs is deployed widely browsers should require both a certificate from
a CA, and that certificate to be in DNS. Two factor authentication for SSL.

~~~
tptacek
If the CA signature means anything, you don't need DNSSEC.

If it doesn't, you've given control over the certificate to Libya.

It is easier to see the problem when you look at the real issue, which is that
the NSA controls _both_ the CA hierarchy _and_ .COM.

~~~
nmc
_Perseids_ made his counter-arguments clear in many places on this page, but
your comment allows me to summarize.

> _If the CA signature means anything, you don 't need DNSSEC._

If DNSSEC is fully deployed and supported, you don't need CAs.

> _If it doesn 't, you've given control over the certificate to Libya._

If it (DNSSEC) isn't, you've given control over the certificate to any trusted
CA in the world.

> _It is easier to see the problem when you look at the real issue, which is
> that the NSA controls both the CA hierarchy and .COM._

Neither DNSSEC nor the CA system can prevent the NSA from doing their evil
stuff.

~~~
tptacek
The problem with the CA system is that it fails to resist nation-state
attacks. DNSSEC not only has that problem, it has it _by design_. That's the
point made by the post. All you've done is restate it.

~~~
nmc
You are right, so let me sum up:

Centralized architecture leaves DNSSEC vulnerable to nation-state attacks.
This is by design.

Decentralized architecture leaves the CA system vulnerable to attacks coming
from any trusted CA. This is by design.

National Security Letters (and their non-US equivalents) leave the CA system
vulnerable to nation-state attacks.

DNSSEC 2 - 1 CAs

~~~
akerl_
Why is DNSSEC not vulnerable to NSLs?

~~~
nmc
I am distinguishing on the attacker, not the means. Sorry if that was not
clear.

Of course DNSSEC is vulnerable to NSLs, but that is not relevant. What is
relevant is:

\- DNSSEC is vulnerable to nation-state attacks.

\- The CA system is vulnerable to nation-state attacks.

\- The CA system is vulnerable to attacks from any CA.

~~~
chopin
Missing points:

\- I, as a user, have mean to circumvent or mitigate CA issues (using
certificate patrol as one possibility, certificate pinning as another,...)

\- There is no user work around for the DNSSEC vulnerabilities

Furthermore, I'd guess that the majority of CA attacks are nation-state
attacks so that both boil down to the same. I don't know of any criminal
attacks (such as attacks on online banking) on the CA's. Conclusion: I, as a
user, don't gain anything from DNSSEC.

------
blumentopf
Reaction when @tqbf, again, claims DNSSEC is NEVER GOING TO HAPPEN

[http://dnsreactions.tumblr.com/post/92623693242/when-tqbf-
ag...](http://dnsreactions.tumblr.com/post/92623693242/when-tqbf-again-claims-
dnssec-is-never-going-to)

~~~
tedunangst
I like this one: [http://dnsreactions.tumblr.com/post/108069740597/dnssec-
ince...](http://dnsreactions.tumblr.com/post/108069740597/dnssec-incentives)

------
marcosdumay
Why all do we get so many articles with missleading text arguing agains DNSSEC
recently?

> DNSSEC is Unnecessary That's opinion.

> DNSSEC is a Government-Controlled PKI And TLS is an all-governments-
> controlled PKI, where any of them can subvert it when they want.

> DNSSEC is Cryptographically Weak Nope, it isn't. But yes, there are people
> using it with weak crypto... Exactly like TLS.

> DNSSEC is Expensive To Adopt A bunch of overblow technical issues that won't
> make any difference on practice. If the domain is being attacked, the lookup
> failed, if there's a configuration problem, the lookup failed.

> DNSSEC is Expensive To Deploy Oh, that's correct. TLS needs an entire hour
> to deploy for the first time, DNSSEC needs some 3 or 4.

> DNSSEC is Incomplete Yep, it's goal is to do the same as the TLS PKI.
> There's DANE for the rest of it.

> DNSSEC is Unsafe Yes, also because it's DANE's job to do that.

> DNSSEC is Architecturally Unsound I can't make any sense out of that.

~~~
tedunangst
Your rebuttal would be a lot more convincing if it were more specific. For
example:

> DNSSEC is Cryptographically Weak Nope, it isn't.

So you're saying that 1024-bit RSA keys are just dandy? You're saying that
PKCS1v15 padding is a good idea?

~~~
marcosdumay
DNSSEC does not mandate any cryptography algorithm. Why are you associating it
with 1024 bit RSA? (I know, because some article appeared here that claimed it
was limited to this. It isn't, and most roots do not use it.)

~~~
tptacek
No article claimed that DNSSEC was limited to RSA-1024, and you clearly
haven't looked at the roots recently.

