A Case Against DNSSEC (A Matasano Miniseries)

Thomas Ptacek | April 2nd, 2007 | Filed Under: Bitching About Protocols, Uncategorized

Back | Top | Next

The head of the Internet Architecture Board has declared DNSSEC a success. The DNSSEC RFCs are standards-tracked. The DNS Extensions Working Group is winding down. Are we finally going to have a secure domain name system?

No. I’ll tell you why I don’t think so:

  • I’ll argue that secure DNS doesn’t solve a real problem.

  • I’ll argue that it’s so complicated and expensive that nobody will ever deploy it.

  • I’ll argue that it’s actually contrary to the design of the Internet.

  • And, I’ll argue that it’s a huge waste of effort; in fact, that the struggle to deploy DNSSEC will do more harm than good.

Let me get started. First, what makes you think we need a secure domain name system?

Because DNS is insecure! Anybody can spoof a DNS response, convincing my browser that my bank’s website is really running on some mafia-controlled Linux box in Uzbekistan!

You’re right. DNS is totally insecure. You can’t trust results coming from DNS.

And that’s a problem!

Not really. You don’t need to trust the DNS anymore. Real-world applications aren’t supposed trust names. At least a few of those applications really don’t, and they seem to work OK.

Want an example? Take my banking website. You can’t spoof it, even if you do own up the DNS, because a third party has to cryptographically attest to my browser that the server has a valid key. Spoofing is prevented at the application layer, not the DNS.

But not every application does that! We can’t keep moving forward with no security in such a core part of the Internet infrastructure.

I agree, in principle. The world would be a better place if the DNS was secure. But in reality, it’s not worth the costs. DNSSEC —- crypto-secured DNS —- is so complicated, unstable, and expensive that it’s not worth the cost.

How can you say it’s unstable? Back that argument up with evidence!

I can’t, which is part of my point. After over 12 years of earnest development, there are still no mainstream deployments of DNSSEC. But I can read an RFC, compare DNSSEC to other protocols, and predict what the operator and user experience is going to be. And it seems like a nightmare.

You know what? I don’t even agree in principle. DNSSEC is a bad thing, even if it does work.

How could that possibly be?

It violates a fundamental design principle of the Internet.

Nonsense. DNSSEC was designed and endorsed by several of the architects of the Internet. What principle would they be violating?

The end-to-end argument in system design. It says that you want to keep the Internet dumb and the applications smart. But DNSSEC does the opposite. It says, “Applications aren’t smart enough to provide security, and end-users pay the price. So we’re going to bake security into the infrastructure.”

What’s wrong with that? IPSEC says the same thing!

Look how well that turned out. But IPSEC is at least optional: it’s so all-or-nothing that the only place anybody thinks to turn it on is VPN links. But DNSSEC isn’t a VPN tool. It’s an anti-phishing tool. Everybody’s going to have to deal with it, whether they have better or simpler ideas for providing security or not —- whether they even need security or not.

It doesn’t even solve the problem of securing the next wave of applications. It can’t, because it doesn’t know what those applications look like. But it’s a pretty safe bet that many of them won’t even use the DNS.

Everything on the Internet uses DNS. The head of the IAB says so.

The head of the IAB didn’t design AOL Instant Messenger, far and away the most important messaging application on the Internet. DNS doesn’t tell me how to find my friends on AIM; AOL’s servers do. AIM isn’t secure right now, but DNSSEC can’t change that. Only the IM developers can. And they can do it without DNSSEC.

The head of the IAB didn’t design peer-to-peer file sharing, far and away the biggest consumer of traffic on the Internet. DNS doesn’t tell me how to find files on a P2P network: the P2P protocols do. P2P isn’t secure right now, but DNSSEC can’t change that. Only the P2P developers can. And they can do it without DNSSEC.

The head of the IAB didn’t design content distribution networks like Akamai, which power many of the most important websites on the Internet. Vanilla DNS doesn’t tell me what mirror to fetch content off of; Akamai’s traffic directors do. I don’t know if Akamai is secure or not, but I’m pretty sure DNSSEC isn’t the deciding factor.

If you think the future of the Internet involves things like overlay networks, peer-to-peer distributed systems, or large-scale web applications like Google and YouTube, you have to ask yourself: where does DNSSEC fit here? These things are happening independently of DNSSEC. They have to be: nobody, not even the IETF, thinks DNSSEC is going to go mainstream in the next 3 years.

There’s more to the Internet than the web. Maybe these people know better than you do. Some of them have been fighting spam and phishing for over a decade. What have you done?

Probably not as much as they have. I’m a mercenary. A creepy security researcher. You probably don’t want to take my word for how to design the Internet.

But you probably don’t want to take their word for it either. There are huge financial implications to how the DNS is architected. A lot is at stake. And despite the billions of dollars spent every year on security, despite the near universal staffing of security teams at every enterprise in the Fortune 500, there’s no detectable market demand for DNSSEC.

DNSSEC gets in the way. It distracts us from real problems that need to get solved. It also substitutes a bunch of IETF people for the judgement and expertise of the market, which actually has a track record in solving security problems. Some of the loudest IETF participants have no qualifications other than willingness to spend time on mailing lists and at conferences.

You’re an asshole.

Indubitably. But convince me —- wait, no, just convince my readers! —- that I’m wrong about this. You just heard my case. I’ll repeat it. Then I’ll go into detail on each point. Again, I’m saying:

  • DNSSEC solves a non-problem.

  • DNSSEC is too complicated to deploy.

  • DNSSEC breaks the Internet.

  • DNSSEC wastes time, energy, and money.

If you want to argue, post a comment. I won’t stop you. If you kick my ass, I’ll put it on the front page. But right now, I think you’re the opposite of right.

Silence

Hello? You there?

Silence

Oh well. I’d better get writing.

Back | Top | Next

Viewing 33 Comments

    • ^
    • v
    From the CoDoNS FAQ:

    What if we widely deployed DNSSEC? Would that fix these problems?

    It would fix some, but not the most significant, of the security problems. If DNSSEC could be widely deployed, it would be harder for attackers to forge records. However, DoS attacks would still be possible, as DNSSEC also relies on the same static nameserver hierarchy as legacy DNS. It might actually be easier to launch DoS attacks with DNSSEC, as the servers have to do more work in response to queries. Most DNSSEC implementations rely on online secrets, so a compromised host would lead to compromised records and redirection attacks similar to the ones described above. DNSSEC would certainly increase DNS name resolution latency, exacerbating the performance problems mentioned below. And it would not help with dynamic updates.

    I don't think it's a question on whether DNS needs to be more secure or not. DNS has security problems. CoDoNS is one answer to most these problems. DNSSEC attempts to solve one problem well, and it does solve that problem - but at a huge cost. DNSSEC is not the solution we're looking for. But I'd argue that we do need a new DNS
    • ^
    • v
    I'm really saying, "it is a question of whether DNS needs to be more secure or not". Maybe it just doesn't matter. That's what I think.
    • ^
    • v
    so with regards to IM--technically, Ian Goldberg and Len Sassman and I'm forgetting a third author fixed the IM security problem with OTR.
    • ^
    • v
    OTR is a good point, but I'm talking more about the weak authentication between iChat/Adium and OSCAR.
    • ^
    • v
    So? Who cares? You get bad auth, you get a new key warning.
    • ^
    • v
    DNSSEC really is end-to-end. Authoritative nameserver to DNSSEC aware application. Having a recursive nameserver validate the answers it is returning really is a stop gap measure for legacy applications. DNSSEC aware applications will turn this intermediate validation off.

    DNSSEC never claimed to prevent phishing attacks. phishing is a name space issue not a data correctness issue.

    You keep claiming that applications should add their own security. DNSSEC does that for the DNS. Remember the DNS is a application in its own right. SSL and IPSEC are not good fits at this level.

    DNSSEC is optional. You don't have to run DNSSEC aware applications or DNSSEC aware nameservers. If you don't
    you are left with the same old DNS that you are used to.

    Having run DNSSEC aware validating recursive nameservers and published DNSSEC signed zones. Including performing key rollovers etc. there isn't (won't be) much more work than there is today with plain DNS. You generate your keys. You sign your zone then you publish it by loading it into your nameserver. Next you pass the DS records to your parent zone in a similar manner as you pass your NS records today. You then just need to remember to periodically re-sign your zone.

    I'll admit that it is a little more complicated today in that you need to actively publish your keys and collect
    trusted keys. However this short term issue as the infrastructure zone providers get their acts together.
    • ^
    • v
    This article is complete nonsense.

    1. As far as the end-to-end principle goes DNS is an /application/. So for DNS to be responsible for its own security is precisely the kind of action the end-to-end principle advocates.

    2. Every other application relies fundamentally on DNS, including those that you cite - AIM or any P2P network. So long as DNS is insecure then any P2P network can be attacked via DNS. Your view that somehow P2P developers can go it alone without DNS is plain wrong.

    3. DNS is one of those technologies where you can pick up the basics in five minutes but it takes years to master. Largely because it has been around so long that plenty of introductory texts exist. DNSSEC does not have these introductory texts and so to someone of limited technical skills may seem daunting. However it is not terribly complicated and when the introductory texts are available that will become clear.
    • ^
    • v
    Jim^H^H^HJay,

    The argument that DNS is an application seems so silly that I don't even know how to address it. If DNS is an application, then so is ARP, RIP, OSPF, BGP, PIM-SM, and the Spanning Tree Protocol. The word has no meaning.

    Of course DNS isn't an application. It's a piece of infrastructure, used exclusively as a building block for actual applications.

    I'll address the rest of these points in subsequent posts. Obviously I think they're crazy talk.

    Mark Andrews, thanks for the reasoned and measured response. I'm not going to earn any politeness or courtesy with my arguments.
    • ^
    • v
    A Different Case Against DNSSEC:

    http://securitytracker.com/alerts/2007/Jan/1017...
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=C...
    http://xforce.iss.net/xforce/xfdb/28745
    http://www.securityfocus.com/bid/22231/discuss

    Wasn't I just making the point like a week ago that security extensions shouldn't be re-engineered into protocols unless a) they reduce the attack surface of its implementations, not increase it and b) the circumvention of the security mechanism outweighs the practicality of exploiting it.

    Interesting that one of those advisories is an SSL advisory. Oh, wait, that's right they're using SSL to handle the RSA key negotiations. Oops. So now not only are our web architectures having their attack surface increased by being reliant on the successful implementation of supplemental security extensions, but now we want DNS implementations to be as well.

    Isn't the fundemental rule of secure development that you want to give the attacker the fewest possible exposed points of failure to exploit?

    Tom makes at least 3 excellent points is this post:

    1) PEBKAC: We have SSL certificates to authenticate web sites, if end users are already falling for accepting bad SSL certs supplied by a MITM; what makes you think they won't accept similar bad DNS messages supplied by a MITM.

    2) Infrastructure is not where you fix problems that exist in the implementation of application layer services: Application developers shouldn't be so lazy as to force their applications to implicitly trust DNS information. gethostbyname() isn't something to build a host-based authentication system around, nor should it be.

    3) Ends don't justify the means: You go through all the effort of generating RSA keys for all of your DNS servers, then you have to inform the underlying resolution architecture on all the platforms you have deployed what the trusted servers are. After all this, you still haven't prevented localized DNS tampering. What about local HOST file resolution? Is that just going to go away? Are we going to start validating host file entries via DNS... Doesn't that defeat the purpose of having them? If all of these attack vectors are maintained, where was the value add of building DNSSEC into the architecture?

    My take on the solution to this problem is this:

    If you need a cryptographic solution for verifying endpoint authenticity, don't use DNS. Use SSL, and and a private CA for issuing certs to clients with validated credentials, it's what it was designed to do. Don't try to build a cryptographic extension into an already insecurely designed protocol. It's like Adam Sandler throwing the newspaper on the pile of puke in 'Big Daddy'.

    I'd also like Jay to explain to me why P2P networks need DNS... Is he insinuating that it's not possible to architect a P2P network without using DNS, that seems a bit naive.
    • ^
    • v
    On a side note, should it bother us that there are people working for a domain registry that think DNS is an application?
    • ^
    • v
    Nah, I'm sure we'd understand what he means if it wasn't for our limited technical skills. :>
    • ^
    • v
    I tried to call my mom to ask about babysitting this week but she was too busy using her DNS browser to send DNS email about the DNS files she was sending to stream through DNStube.

    And yes, the emotion I'm trying to evoke with "IETF people instead of the market" and arguing whether DNS is an application is, "profound, unpleasant concern".

    About 7 years ago I started a company with Dave Meltzer and Danny Dulai doing streaming media delivery over a multicast-routed overlay network. A couple other companies did it better (like FastForward) and we got crushed, but I got to pay attention to what people said to them: "you can't do multicast at the application layer! It's a gross layering violation!".

    I'm really bothered by the thought that the IETF is populated by people who think that the OSI model --- again, O S I, people --- is the Talmudic kernel of protocol design. So that something is an "application" if it uses BSD DGRAM sockets to communicate, but "infrastructure" if it's hooked up directly to software interrupts in the kernel.

    Leave aside the notion that the OSI model doesn't capture the Internet stack well: if you divide the world up into "transport, infrastructure, and applications", "infrastructure" is "anything you build on AND never use by itself". DNS is infrastructure. You could replace it and, as long as you didn't break libresolve and whatever the hell Win32 uses, nobody would *ever* notice. Just like I don't care how you reinforce the concrete in my building but I do care about how my desk is built. Infrastructure, applications. NOT HARD.

    I feel bad being a dick about this because Mark Andrews took the time to write a polite response, without evoking the "I'm from the IETF, and what RFCs have YOU written" sentiment that Jay did. Mark is clearly more important than Jay and I'm casting aspersions on both of them. Oh well, omelettes, broken eggs.
    • ^
    • v
    Scary sidenote: Dan Kaminsky does use DNS browsers to send DNS mail about the DNS files he streams through DNStube.
    • ^
    • v
    Of course, I feel compelled to mention that Dan Kaminsky's solution to getting secure DNS lookups is to proxy them to a trusted network over an SSH tunnel... which of course is running on top of DNS. I believe his line at this point is "Malkovich Malkovich Malkovich."
    • ^
    • v
    I'm surprised that you resort to inventing something to attack in order to defend your position. As it happens, I've never written an RFC and only occasionally post to IETF mailing list. Not realy the IETF person you seem to want to demonise.

    Anyway, back to the technology:

    It's easy enough to tell the difference between an application and infrastructure. Does it normally run on a router on an end computer. That's why the routing protocols you list are infrastructure and DNS is an application.

    You even say yourself that people use DNS as a building block for applications - more proof that it is an application. The only applications that are built using RIP, OSPF etc are specialist network applications. To all other applications they are completely invisible - a sign of true infrastructure.
    • ^
    • v
    Jon

    Nobody is saying that applications should leave security to DNSSEC. Also nobody is sayin that DNSSEC verifies endpoint security. All it does, as you should expect, is secure DNS.

    Host file entries don't need validating because you put them there. DNSSEC is about securing messages you receive from other people.

    All DNSSEC does is let you verify that the DNS data you receive is the DNS data that was sent to you. It makes no assertions about the endpoints.

    On the P2P point:

    OK, with some effort you can avoid the direct use of DNS entirely. You can write your own name resolution protocol and to bootstrap the network discovery you can define some well known IP addresses in your application and ensure they always respond.

    But seriously though, who is going to go to all that trouble? The name resolution side, sure some people do that, but the bootstrap as well?

    I was wrong to say that people can't write P2P without DNS. It is more correct to say that people /don't/ write P2P without DNS.
    • ^
    • v
    Jay: your acid test for "infrastructure" vs. "application" breaks for route servers and any network more than 7 years old. There's a reason BSD ships with "routed" --- people actually used it.

    Can you take another cut at what differentiates "infrastructure" from "application"? You've put DHCP firmly in the "application" category. Also, ARP.

    It's obviously not "computer" vs. "router".

    Maybe it's "desktop" vs. "server"? I totally buy that. Of course, that leaves DNS in the infrastructure.

    Either way it seems pretty obvious to me that DNS is not an application. In that nobody sits down to "use" DNS.
    • ^
    • v
    With regard to "who's going to go through the trouble of using an alternate name service instead of DNS", I offer as counterexamples every IM protocol in current use, every P2P protocol in current use, and Google.
    • ^
    • v
    By 'router' and 'end computer' I mean the functions they are used for, not whether they come with a GUI or an Intel-inside badge. That's why I used the term 'end computer'.

    When someone writes an application they use gethostbyname or the equivalent. So DNS is not transparent to them. Routing protocols like RIP are entirely transparent unless they are writing network specific applications.

    The test works pretty well.

    On the P2P side my point was that any P2P app that wants to be free of DNS /must/ do two things
    - its own name resolution
    - its own non-DNS bootstrap

    Yes some apps do the first but almost none do the second. So they do rely on DNS somewhere.
    • ^
    • v
    So, by your take, MBONE "wb" is an infrastructure tool, but BitTorrent is an application. Good test!
    • ^
    • v
    I mean less offense than it sounds like I do. I just find the distinction you're making totally artificial. Applications are things people overtly use. Nobody overtly uses DNS.
    • ^
    • v
    Except Dan Kaminsky.
    • ^
    • v
    RFC1123: Requirements for Internet Hosts - Application and Support lists DNS requirements as part of support services (not as an application) and it specifically says that every host MUST implement a resolver and MUST use it to convert hostnames to IP addresses. Therefore, if every host on the Internet MUST rely on the DNS system for host name resolution, it is evident (at least to me) that the DNS system is part of the Internet infrastructure.

    Disregarding the RFC and how the IETF may think about this, my test to determine if X is infrastructure or not is simple and maybe a bit naive, I ask myself: does the Internet work without X? If the answer is no then X is part of the infrastructure otherwise X is not part of the infrastructure.
    • ^
    • v
    An application developer can choose not to use DNS. They cannot choose whether or not to use a routing protocol if that is implemented on their network path somewhere.
    • ^
    • v
    They can also choose not to use IP. Why are you being evasive?
    • ^
    • v
    If DNS were just a directory of Internet hosts the argument given above against DNSSEC would be valid. But DNS already supports directories of many more things than hosts, e.g. email reputation lists, organisation address lists and phone books.

    The need for DNSSEC and all its relative complexity arises when we start considering Internet support at lower levels of layering for the kind of message we call money in all its potential forms, with DNSSEC directly providing the kind of directory we call bank and payment accounts so that a future payment can be routed between the correct accounts. Here the cost of doing this directly supported by DNSSEC will potentially be much less than the current cost of an online Visa or Paypal transaction supported by TLS/SSL and all the traditional banking protocols that sit on top and which typically cost merchants 6% of the transaction value and which are not economical for payments of less than $5.

    In my understanding it is possible to get this cost down to the point where every payment of a bus fare or supermarket coupon is an almost zero cost Internet message. The main cost of this will become the manual effort of checking your monthly statement, which getting everything online will help you to automate to an extent. However, this requires a more inherently secure directory than DNS in its current form.
    • ^
    • v
    I don't get it. What's the cost of an SSL/TLS transaction? You realize the CA's don't charge *per connection*, right?

    Even having said that: if CA's charging $30 for BER bits bugs you --- and it bugs me too --- then the problem to solve is getting a trusted, secure "public" CA. That's not a technical problem.
    • ^
    • v
    The point I'm making is that DNS as it stands is adequate for the kind of directory service that it is currently used for but this stretches to meet the requirements when money is involved to the point were monetary transactions are much more expensive than they need to be. This in turn causes a drag on the whole economy and slows the digitisation of money as a whole system. It's a bit like a telecom last mile problem. Currently digital cash and the new forms of currency this makes possible cost too much to do the accounting for this to be viable in many applications.

    With DNSSEC it becomes possible to design directories which are secure enough to be used for monetary identities for everyone - not just merchants who can jump through all the hoops currently involved in setting up a merchant account.

    This is because with DNSSEC the certificates will delegate through the domain registration process. If the syntax differs between
    my_account_number@example.bank and my_account_number.example.bank the semantics don't as example.bank obtains it's certificate from the .bank TLD key and my_account_number obtains its certificate from example.bank . The syntax and semantics of the certificate chain are crucial if there is any possibility of identity being misread i.e. phishing. Also we can expect the .bank TLD to be a lot more careful about certification than .com , and consequently it's certificates will be trusted to a much greater extent and rightly so.

    So I think that DNSSEC does solve a genuine problem, though the cost of it doesn't justify being applied to applications that don't need it, until the development cost has been carried by those that do to the point where scale and further technical development makes DNSSEC cheap enough to improve other directory applications.

    I'm going to be away from the Net for a week but will check back then.
    • ^
    • v
    Thomas -- the cost of SSL/TLS is not the money to get the certificate. The cost is the transactional overhead of doing the crypto and setting up the connection.

    I'd like to see you do 15,000-25,000 SSL-enabled web transactions per second on a single machine with just one CPU. I've seen nameservers that can do that many authoritative queries per second. Add SSL/TLS to that mix, and the number will drop -- by orders of magnitude.

    And many of the most important nameservers are already vastly overloaded by the crap they've got to deal with today.


    Personally, I think we can solve a lot of the DNS security issues by simply requiring (and enforcing) good administrative principles whereby we enforce a separation between the authoritative and caching-only functions, and we carefully vette the incoming traffic to only allow those types of queries and transactions that we know to be "safe".

    DNSSEC is useful and serves a purpose, but I don't think that cache poisoning/pollution and phishing are the right problems to be trying to use it to solve. Those can be solved in other ways, leaving us to use DNSSEC to solve harder problems in other areas.
    • ^
    • v
    Brad: why are we overhauling the DNS to create an IETF/IANA-owned PKI? What makes you think there's one PKI design that will solve most applications problems? And how much credibility does DNSSEC have at this point as the vehicle for solving those problems?
    • ^
    • v
    Here's the paragraph I disagree with:

    DNSSEC gets in the way. It distracts us from real problems that need to get solved. It also substitutes a bunch of IETF people for the judgement and expertise of the market, which actually has a track record in solving security problems. Some of the loudest IETF participants have no qualifications other than willingness to spend time on mailing lists and at conferences.

    1. Most security staff make a point of being distracted from solving real problems. If it wasn't DNSSEC it would be something else.
    2. The security market is ineffective - see the economics and security literature.
    3. Arguments need to be judged by something better than loudness.
    • ^
    • v
    A few things that stand out here --
    - DNSSEC is way past its need-by time.
    - It will be an addition that very few applications/services use/require.
    - Companies will try to market their crappy products on the back of DNSSEC.

    But if they could find a good use case for IPSec (VPN) then why not see what happens with DNSSEC? I agree that it is totally redundant and that any problem could be solved without using DNSSEC.
    • ^
    • v
    Because you can try IPSEC out on your VPN without screwing anything else up. But to deploy DNSSEC, we have to forklift it in to the DNS hierarchy.

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus