Against DNSSEC

http://sockpuppet.org/blog/2015/01/15/against-dnssec/

by tptacek • 12 years ago

186 144 12 years ago

zdw• 12 years ago

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/

marcosdumay3• 12 years ago

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?

ctz• 12 years ago

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.

blfr• 12 years ago

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.

tptacek27• 12 years ago

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.

ploxiln2• 12 years ago

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

danyork3• 12 years ago

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/

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.

tptacek27• 12 years ago

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?

nmc6• 12 years ago

"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)

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

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

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

danyork3• 12 years ago

Hmm... I'm not sure where you are seeing that claim that 10% of DNS requests are signed with DNSSEC. I've certainly promoted the statistic that 10-12% of DNS requests are performing DNSSEC validation - and that is based on Geoff Huston's DNSSEC validation metrics out of APNIC - see: http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g... (although the measurement seems broken for the past few days)

Perseids5• 12 years ago

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

Assume we are attacking example.tld

For the US government: 1a) Use the root zone keys -- that are essentially already under their control -- to sign fake zone keys for fake .tld nameservers. 2a) Continue with 2b) below.

For the government under whose jurisdiction the .tld zone is operated: 1b) Get the zone keys for .tld using legal measures (e.g. the local equivalent of national security letters). 2b) Use the .tld zone key to sign fake example.tld zone keys for fake example.tld nameservers. 3) Serve signed records for example.tld records (via man-in-the-middle attacks).

xorcist12• 12 years ago

This in practice a redelegation of the zone.

If you redelegate a zone to a new owner, that owner owns the domain for every intent and purpose, including generating signed TLS keys from pretty much any CA.

There are legitimate ways to delegate a zone, including selling it to someone else. It's not really an attack, and it's definitively not something you can protect against.

xenophonf3• 12 years ago

attacks by a government against DNSSEC

When people talk about government attacks against DNSSEC, I assume that means co-opting the TLD operator and feeding alternate, signed, validated-to-the-DNS-root copies of a particular domain to some target. Is that not the mode of attack being described?

marcosdumay3• 12 years ago

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.

danyork3• 12 years ago

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

I don't know, but perhaps because DNSSEC deployment IS happening... and the critics want to stamp that down. :-(

tptacek27• 12 years ago

Dan: which of the parent commenter's arguments do you buy?

tedunangst4• 12 years ago

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?

marcosdumay3• 12 years ago

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

erglkjahlkh• 12 years ago

puts on his compliance hat

Many organizations are mandated (by statutes etc) to use elliptic curve based cryptography already. It is not because RSA is broken, but because the key sizes would have to be uneconomically large.

The key size requirements are picked based on the advancement rate of technology (mathematics, calculation power / price), and the time the data should stay protected. Many security related standards aim for several decades, and for RSA key sizes that does not look so good.

If the system is not already in wide usage, rolling out a major protocol that does not contain support for ECC at this time is a very, very bad choice. Many organizations have simply to disable it already because it violates the requirements. (Oddly I have seen being not encrypted not violate anything, because "that's the way DNS is"... Go figure)

ta78787• 12 years ago

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?

jimktrains2• 12 years ago

I think people are referring to this: http://en.wikipedia.org/wiki/Zooko%27s_triangle

Zooko's triangle is a diagram named after Zooko Wilcox-O'Hearn which sets out a conjecture for any system for giving names to participants in a network protocol. At the vertices of the triangle are three properties that are generally considered desirable for such names:[1]
Human-meaningful: The quality of meaningfulness and memorability to the users of the naming system. Domain names and nicknaming are naming systems that are highly memorable.
Decentralized: The lack of a centralized authority for determining the meaning of a name. Instead, measures such as a Web of trust are used.
Secure: The quality that there is one, unique and specific entity to which the name maps. For instance, domain names are unique because there is just one party able to prove that they are the owner of each domain name.

peterwwillis2• 12 years ago

Not secret, Secure. Secret is overrated.

wmf2• 12 years ago

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.

ploxiln2• 12 years ago

Companies want security through obscurity, in this case for internal-network servers. Makes CTOs feel better, and security consultants are in the business of making CTOs feel good, so they want it too.

oasisbob• 12 years ago

Staging sites which need to interoperate with a third-party are one place I've seen obscured hostnames used.

eg, You want to test some front-end changes in conjunction with changes to the CDN config. If the production site is origin.example.com, the staging site might be at origin-stage-asdgwdse.example.com because you (hope!) the changes don't leak early.

IPv4 literal addresses are often inconvenient / not feasible for larger stacks or cloud setups where you don't control the underlying infrastructure.

seccess• 12 years ago

I don't think DNSSEC ensures the hostnames are secret. From RFC 4033 [0]:

"The DNS security extensions provide origin authentication and integrity protection for DNS data, as well as a means of public key distribution. These extensions do not provide confidentiality."

[0] http://tools.ietf.org/html/rfc4033

cdjk3• 12 years ago

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.

tptacek27• 12 years ago

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

cpach3• 12 years ago

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

(Edit: If they are caught.)

cdjk3• 12 years ago

So isn't that a criticism of domain-validated certificates? This is a serious question. I haven't heard a compelling argument for how DNSSEC/DANE gives governments any more power than existing DNS delegation.

acdha3• 12 years ago

I think the issue isn't that this is somehow worse but simply that DNSSEC is redundant to the fixes which we already need to make (e.g. public key pinning) so you're left with the question of deploying something which doesn't make you more secure and does provide a new way for things to break.

revasm2• 12 years ago

Public key pinning seems to be heading in a direction that relies on the current CA model. For example, see https://tools.ietf.org/html/draft-ietf-websec-key-pinning-20, or https://code.google.com/p/chromium/codesearch#chromium/src/n... (Chrome's pinned certificate list -- which has a total of _9_ non-CA entries).

peterwwillis2• 12 years ago

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.

colmmacc3• 12 years ago

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.

ryanlol• 12 years ago

1) Is not a valid argument, or at least shouldn't be. By that logic we should completely drop UDP.

ryan-c2• 12 years ago

On-the-fly signing (with "white lies") is also required to prevent enumeration of the zone.

leni536• 12 years ago

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• 12 years ago

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.

richardwhiuk2• 12 years ago

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

tptacek27• 12 years ago

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.

richardwhiuk2• 12 years ago

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.

cs02rm0• 12 years ago

There are better DNS security proposals circulating already.

Tease.

wglb4• 12 years ago

Perhaps he is referring to http://dnscurve.org/

xorcist12• 12 years ago

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

xorcist12• 12 years ago

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.

tptacek27• 12 years ago

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.

sarciszewski2• 12 years ago

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

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

smutticus• 12 years ago

DNSSEC is a government-controlled PKI.

This needs to be better explained in depth. Do world governments control DNS because of ICANN's GAC? Does the USG control DNS because ICANN is contracted to the NTIA? Are the root key creators USG agents? What is your reasoning behind world governments controlling DNS and/or DNSSEC?

I can't argue against this statement because it's not clear to me what you actually mean.

wtbob• 12 years ago

The problem is that DANE's replacement for the TLS PKI is controlled by world governments.

I think that the concept (though not DANE itself) could be made to work, e.g. by using k-of-n systems to verify that a majority of governments agree to a particular fact. If the US, UK, Russia, Iran and Ghana all agree on a set of facts, those facts are likely to be true; if enough nation-states agree on a set of facts, then those facts might as well be true.

This could be used to secure the root for a nation-state's DNS, since that root is, after all, just a fact.

As an example, a majority of member states could certify that the ICANN board has authority for the root; a majority of the ICANN board could certify that 192.0.2.27 is authoritative for .example; in exactly the same way, 192.0.2.27 could then use its authority to delegate responsibility for example.example to 203.0.113.153, and so forth.

A similar scheme could be used for IP address ownership.

Yeah, any nation state is going to be able to lie about the identity of machines it is responsible for—but it's a government; it can do that anyway. Other approaches like TOFUPOP help there, but at the end of the day the guys who can point guns at a certificate holder have the ability to make him do anything anyway.

xorcist12• 12 years ago

I thought I was perfectly clear in which points were not yours. My point with including the whole list of standard arguments against DNSSEC, not only yours, was that they are well known to DNS implementors for over ten years.

1. Since you decide that the whole of DNS is "government controlled" (which is a statement of a kind that are useless to discuss furhter), you must also accept that "a race to the bottom in CA pricing" means certficates generated without human intervention. That would mean a very complex and error prone to implement the same security model as DANE gives you, where domain ownership is cryptographically assured.

2. That is only because "government controlled" is a meaningless phrase. ICANN is not more government controlled than any other organization operating in a jurisdiction. They have a mandate from the US Department of Commerce but that does not mean they are "controlled" by them. It could certainly improve, but the proposals for a multi stakeholder model has so far been thinly veiled attemts to politicize ICANN. That does not mean it can not be done. The fact that they root zone has a spotless record of political meddling so far should count for something.

3. This last statement is incorrect. DNSSEC is not RSA-1024 for the forseeable future. Implementating an alternative way to secure DNS with more modern cryptography is many orders of magnitude more difficult than switching algorithms in DNSSEC, which is completely supported.

4. Again a statement so general it holds true for implementing any world wide standard. If you want every software under the sun to handle lookup failures correctly, that is expensive in itself. Is DNSSEC more expensive than any reasonable alternative? No, probably less so. Failure modes are well understood.

Since the rest of the points weren't raised by you directly (but then again, many times by others) I think we can concede them from any further discussion.

codexon• 12 years ago

Better deployment of filters would do much to improve the situation.

No, it wouldn't. People have been calling for an to end spoofing for 15 years with virtually 0 progress.

Filters don't help in volumetric attacks.

Perseids5• 12 years ago

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?

tptacek27• 12 years ago

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.

blumentopf4• 12 years ago

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.

Perseids5• 12 years ago

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?

(The link tptacek is referring to is https://gist.github.com/tqbf/e8d82d614d1fea03476b btw.)

If I had my say, the code you link to would not have to be changed at all, because the `gethostbyname` interface would stay the same and return a lookup failure on unsuccessful DNSSEC verifications, if the parent zone reports the domain to be DNSSEC enabled.

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've said so in your blog post, but you don't say why. Everyone that is seriously considering using DANE as a replacement to the existing CA hierarchy assumes they do include a DNSSEC enhanced resolver (I don't see why it has to be a "full" and caching resolver, though).

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.

When the "last mile" is on my PC (i.e. when my local resolver checks the DNSSEC signatures) then it is as protected as my OS.

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.

While I find your enthusiasm to protect against the NSA encouraging and important, my point actually was that DANE improves upon the security of the existing CA system against attacks by non state-sponsored attackers and foreign state-sponsored attackers beside the NSA.

Let me state it differently: At the moment, example.de has to worry about attackers controlling the .de zone (, the root zone) and attackers controlling any of the >100 CAs (including many nation states). With DANE, example.de only has to worry about attackers controlling the .de zone and the root zone. As a more graphic example consider how at the moment the "Deutscher Sparkassen Verlag GmbH", the CA of a german umbrella organization of local banks, can issue certificates for amazon.com, wikipedia.org or any other domain world wide. This kind of nonsense is solved by DANE, not NSA spying.

(My apologies to German readers for not inflecting "Deutscher" in the above sentence. I keep the identifier verbatim to allow readers to look it up via non-fuzzy search.)

linkregister• 12 years ago

I have a question. Your article's reference for "governments control the DNS" just describes public in rem legal actions by the Justice Department to Verisign to seize domains. How does that imply control? By that logic, wouldn't it be a valid statement to say "Matasano is controlled by the US Government (i.e., the NSA)" because it's only one in rem legal action away from injunction?

I'm just asking for clarification for the statement; I'm in agreement with the crux of your argument. I just don't understand how the Government(s) control DNS more or less than any other aspect of the internet that is vulnerable to meatspace attacks like injunctions and arrests.

EDIT: I think I understand the distinction now. Your argument is saying "the CAs are bad but we mustn't allow DNSSEC to replace them." And a domain's TLS certificate is safe from an individual government's subversion if the CA resides outside of that government's jurisdiction.

Am I understanding this correctly?

groks• 12 years ago

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

Fedora 22 feature change request: https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Res...

xorcist12• 12 years ago

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

You phrase it like a fact. In practice we're seeing quite the opposite. Firefox clearly sees a fully validating client as the only reliable way to implement TLSA.

worklogin• 12 years ago

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?

tptacek27• 12 years ago

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.

wmf2• 12 years ago

Isn't the signer for .com the same as the owner of .com, so if they misbehave then your DNS resolution could be broken regardless of DNSSEC?

wglb4• 12 years ago

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

Tharkun• 12 years ago

Relying on Google to mitigate problems sounds a lot like centralization to me.

dsacco• 12 years ago

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.

colmmacc3• 12 years ago

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.

tptacek27• 12 years ago

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.

nmc6• 12 years ago

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

Entirely false! ! ! Please get your facts right. [Not talking about the 2nd part of your comment]

Yes, the Turkish government hijacked the Turkish DNS resolvers, so they were returning incorrect IPs for the twitter.com domain.

Yes, DNSSEC would have helped. The Turkish government does not have any of:

- The keys for the root zone

- The keys for the .com TLD

- The keys for the twitter.com domain

As a result, the Turkish government had no way to forge signatures for the twitter.com domain. All they could do was send a fake AD bit.

Using DNSSEC to validate answers for twitter.com from Turkey during the hijack would have failed. That is the exact purpose of DNSSEC.

blumentopf4• 12 years ago

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

http://dnsreactions.tumblr.com/post/92623693242/when-tqbf-ag...

tedunangst4• 12 years ago

I like this one: http://dnsreactions.tumblr.com/post/108069740597/dnssec-ince...

silisili2• 12 years ago

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.

tptacek27• 12 years ago

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.

silisili2• 12 years ago

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.

ryan-c2• 12 years ago

IIRC when I crawled the alexa top million's DNSKEY records none of them used ECC. I did see a few using DSA.

AlyssaRowan2• 12 years ago

I'm using DANE on most of mine, but the public-key pinning + CA usage of it - so an MITM would need to either steal signing keys, or a pocket CA and to swap my DS record. Not impossible but it's an extra barrier (instead of a replacement for the PKIX). With free certs on the near horizon from Let's Encrypt as well, then the two together allow two independent barriers, one with certificate transparency, and that may work quite well for domain validation in practice.

The country that owns/operates the TLD I'm under, or the registrar, can already swap my DNS, but DNSSEC makes it harder for others to. I don't know what more we can do about that - probably more in the realms of I2P or Tor, etc.

DNSSEC has definitely got some problems. The reflection problem, for one, which needs careful mitigation. And yes, it could use modern crypto badly, but that's waiting on standardisation; signatures are a way off in CFRG and then there's all the HSMs. It may be better as part of a nutritious layering breakfast; DNSCurve on top, maybe?

You won't see me arguing for plaintext anything, however, so if unsigned plaintext is the alternative, bugger that. QUANTUMDNS is just way too easy as a man-on-the-side otherwise.

BGP is a total clusterfuck and needs a lot of security it doesn't have - that's about all I can say as to that.

xenophonf3• 12 years ago

Note that only SHA-1 and RSA must be supported by conforming DNSSEC implementations; see RFC 4034. That's probably why support for other ciphers or hash algorithms is inconsistent at best.

efesak• 12 years ago

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

tptacek27• 12 years ago

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

xorcist12• 12 years ago

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

eltrai2• 12 years ago

So ?

It might be worse than securing it yourself, but it's still way better than no security at all.

IgorPartola2• 12 years ago

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?

tptacek27• 12 years ago

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.

IgorPartola2• 12 years ago

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.

Against DNSSEC

Related Stories