A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek | April 3rd, 2007 | Filed Under: Bitching About Protocols, Uncategorized

Back | Top | Next

1.

Alice and Bob want to talk.

mitm1.png

Mallory wants to get in on the action.

mitm2.png

With unprotected IP and HTTP, Mallory can do that. In fact, it’s really easy; Mallory doesn’t even have to be in the middle. We’ve idealized Alice and Bob. But Alice needs to use the DNS to find Bob.

mitm3.png

If Mallory can spoof the DNS, she can get between Alice and Bob. Mean ‘ol Mallory!

mitm4.png

Alice is my mom. Bob is Bank of America. Mallory is the Russian Mafia. I care a lot about this attack.

2.

So does everyone else, since, like, 1994, when someone installed SunSniff on a machine plugged into a colo Ethernet link that was part of the Internet backbone and sniffed everyone’s passwords. So, before Bank of America got on the Internet, everyone solved this problem:

mitm5.png

This is SSL/TLS. SSL/TLS is one solution to the problem of eavesdroppers and man-in-the-middle attackers. It relies on certificate authorities.

Alice is using a browser pre-configured with the public keys of several trusted third parties. These public keys are “trust anchors”. Bob arranges with one of these third parties to get “certificate”, which says, “I’m really Bob, and here’s my public key”. Bob’s server presents this certificate to Alice when she connects, as part of the TLS handshake. Alice and Bob use their public and private keys to agree on an ephemeral AES session key, which protects all future communication between them.

This is a really, really nice protocol.

You don’t know it just to look at it, though. It relies on X.509, which is an ASN.1 protocol. ASN.1 is to the Internet what Pravda is to the GOP. SSL/TLS has its own record layer. Ew! It has a really complicated handshake. Lots of negotiation. And the certificates are hard to configure. And you have to talk to creepy Certificate Authority companies who want you to pay for the privilege.

On the other hand, Mallory is clever and has a lot of ways to attack a crypto protocol. And SSL/TLS accounts for all of them. Mallory will fake messages try to get Alice and Bob to agree to an insecure version of the protocol. She can’t; the handshake has a built-in integrity check. Mallory will try to replay messages. Nope. Mallory will break MD5 AND SHA1. Still no luck! The protocol uses both!

SSL/TLS says, as long as you can trust one trusted third party, who’s only job is to protect cryptographic secrets, and who will certainly go out of business if they are completely compromised, you’re safe. (Well, OK, you have to trust your ability to read, and your browser, too). And if you don’t want to trust a third party, you can set up your own certificate authority.

SSL/TLS protects virtually all secure web transactions.

3.

Don’t like SSL/TLS? Ok, you have another option:

mitm6.png

This is PGP/GPG. Alice and Bob can directly swap public keys. They can use their private keys to generate messages that only they can read, and that can only come from them. The difference is, instead of trusting a certificate authority, they trust a file format. This is web of trust, although that’s kind of an overblown name for “I can read you a fingerprint of my public key over the phone so you know you got the right one, and I know I have your key because my best friend gave it to me”.

PGP/GPG protects virtually all secure email. We use GPG. Our secret messages are decidedly worth intercepting. It works well.

4.

Don’t like PGP/GPG? Ok, you have another option:

mitm7.png

This is SSH. Alice and Bob can trade public keys the first time they talk to each other. They can use their private keys to generate session keys that protect all future communications between them, just like SSL/TLS. They know they have the right keys because they remember the first time they kissed; if Mallory comes between them, her key will necessarilly be different. This is called key continuity.

SSH protects virtually all secure Unix and router administration. Like everyone else, we use SSH.

Note that in all three cases, I made no mention of the DNS. In all three cases, Mallory continued to own the DNS. In fact, I put Mallory right in the middle between Alice and Bob. That’s better than owning the DNS. I gave Mallory the pipe. And Mallory still can’t win. Alice and Bob have end-to-end protection.

5.

Mallory can still mess with Alice and Bob though. She can drop their packets on the floor. Or worse! She can redirect their DNS messages! This keeps Alice and Bob from talking to each other. Denial of service!

This really skeeves the IETF DNS people out. DNS is involved, in some way, in almost every transaction on the Internet. People should be able to talk to each other, and trust that they’re talking to who they think they are. Even if they don’t want to use TLS or GPG:

mitm8.png

This is DNSSEC. Sort of. It protects the DNS sort of the same way TLS protects the web: Alice and Bob have “trust anchors” that let them verify public keys from DNS servers. Alice can trust results from the DNS. Alice can find Bob, and Mallory can’t trick her.

At least, not that way. Please note the obvious problem here. Securing the DNS protects DNS lookups. But Alice and Bob still need another layer of security, because Mallory owns the pipe and can see their packets. In practical terms, Mallory can grab Alice’s HTTP cookies, log into the bank right after she does, and the idempotent HTTP application on the bank’s server won’t do anything to stop her.

7.

This sucks! But it gets worse. Note the trust relationships in TLS, GPG, and SSH:

  • In TLS, you have a trust a Certificate Authority, who gets paid to protect your secrets.

  • In GPG, you have to trust your friends.

  • In SSH, you have to trust your memory.

But, going back to DNS 101, there isn’t just one DNS authority. DNS is distributed. A lot. Each portion of the namespace is governed by a different entity. You have to trust all of them.

mitm9.png

And the people who manage domain namespace aren’t (typically) security people.

In fact, DNS spoofing is pretty rare (there are much, much easier attacks that are way more effective). But most of the time, when it happens, it’s not because Mallory played packet tricks with Alice’s DNS requests. Nope:

mitm10.png

Mallory lived through the late ’90s and learned, from software like BIND, how exploit scripts work. My browser trusts tens of Certificate Authorities, and presumably they’re all reasonably hard to crack. But there are tens of thousands of DNS servers, all responsible for their own DNSSEC security. Mallory’s just gonna go own one of them up.

Now, DNSSEC is not retarded. Mallory can’t bust up Southern Illinois University’s authority servers and spoof Bank of America. But there are way more DNS servers than GPG and SSH keys. There may be more of them than there are current TLS certificates. And a compromised DNS server is more powerful than a single compromised certificate; it lets you synthesize arbitrary names under the authority of the server.

DNSSEC does nothing to account for this attack, which is the most likely vector Mallory will use to subvert the DNS.

Another attack DNSSEC does nothing to account for is Denial of Service. Like I pointed out, if you’re using TLS, there’s nothing Mallory can do to you except keep you from talking. But even if Mallory doesn’t own the pipe, she can still mess with you by saturating your DNS servers with requests (for instance, by making them walk absurd and ambiguous chains of keys). DNSSEC is not a lightweight protocol, and its authors explicitly exempted DOS from the problems it contemplates. A confession: this isn’t my argument; it’s Christian Huitema’s.

And DNS isn’t the only infrastructure protocol that connects Alice to Bob. Even if you secure the DNS, Mallory can still go after:

  • DHCP

  • ARP

  • Anycast Routing

  • VLAN trunking protocols

  • IGPs like RIP and OSPF

  • EGPs (meaning, BGP4)

Successful attacks on any of these protocols —- which have actually happened in the real world —- give Mallory the pipe again. Alice’s DNS requests are secure, but her messages to Bob aren’t. In theory, we should secure all of these protocols, too. But it took over 13 years to agree on how to secure the DNS, and the DNS is simpler than some of these protocols.

Finally, and to my mind most importantly, DNSSEC does nothing to address the problem of insecure implementations. There’s some basic remedial math my readers are pretty familiar with —- as is anyone who read Schneier’s “Practical Cryptography”: more code = more complexity = more bugs.

Look at the BIND security page; bugs that involve SIG, or EDNS, or OpenSSL, or “validation”, or TSIG —- those are vulnerabilities caused by DNSSEC code.

Alex Bligh made this point for me on the Namedroppers list:

I would suggest this [the DNS is already secure] is a minority view. Else we’d have spent the past 15 years fixing implementations as opposed to protocols.

Well, I know how I spent the last 15 (well, 13) years. And I guess I know how Alex Bligh thinks he spent the last 15 years. You tell me which was more important.

Back | Top | Next

Viewing 33 Comments

    • ^
    • v
    I don't consider DNS insecure as a protocol only because I don't buy into the assumption that DNS must be secure.

    Does that mean I think it is perfect and secure? Of course not, but it does the job it should do. I'm not sympathetic to the view that DNS needs bloating, necessarily...

    I will say I don't like the dismissal of DoS as an attack against DNSSEC. If attackers can just bring it down, all that other security seems pretty useless.
    • ^
    • v
    To be fair, the dirty secret is that for the most part, cryptographically secure, highly transactional protocols like DNSSEC and HTTPS are all susceptable to DOS.

    This is like, 90% of the motivation behind Bernstein's work on high-speed crypto and, in particular, high-speed signing schemes.

    Having spent over 4 years at Arbor Networks, half of that in charge of their DoS product, which is deployed everywhere, I'm suspicious of any argument that says that DOS attacks are unimporant. The amount of effort people put into DOS is startling. And there's easy money in it: you just extort protection money out of casinos.

    But just because they are important doesn't mean they need to be solved inside the protocol.

    On the other hand, when a protocol's sole obvious benefit is being in a position to prevent DoS attacks, punting on DoS is a bit weird. That's a caricature of an argument though, presuming that you, like me, believe that all the rest of the "problems" DNSSEC "solves" are kind of silly.
    • ^
    • v
    Couple things:

    Just to clarify, you're not arguing against the possible utility of unspoofable name lookups, right? Just that DNSSEC isn't it?

    Or are you saying there's no point at all, and are concerned about the time wasted working on it?

    Because I think I'd like to have the threat of name lookup spoofing removed to whatever degree possible, as an ideal.

    Second, I'm trying to puzzle out whether you may be high, regarding more DNS servers in the world than SSH keys.

    Things I can think of that are DNS Servers:
    -Intentional, dedicated DNS servers
    -Windows AD/DHCP/WINS boxen
    -$40 linksys/dlink home routers?
    -(Potentially) every *nix box and Windows Server box?

    I'm reluctant to count much from the last bullet. While I'm sure most *nixes ship with DNS Server(s), I'm guessing they aren't on out of the box.

    Other guesses are on the order of 9 million?
    http://www.domaininformer.com/news/press/061009...

    Now, SSH. I can't seem to find a simple OS market share link with just numbers instead of percentages, but I see a few that have "unix" looking in the neighborhood of 15-20% of the machines, and that's out of some few hundreds of millions of machines?

    So, I dunno, 50 millions *nix boxes in the world?

    I think a big chunk of those will be running SSH. I think most SSH Server installs will be generating the Server keys the first time you boot. Plus some possible multiples for user-side keys.

    I believe some portion of those $40 routers also do SSH. While heisenburging, I'm perfectly willing to count the number of Windows boxes running SSH servers as zero.

    So, back of my envelope says you're high.
    • ^
    • v
    I may be high.
    • ^
    • v
    Oh and, I'm saying, "don't waste time trying to make DNS reliable".
    • ^
    • v
    If I got to be king of the Internet, like Paul Mockapetris, Jim Reid, and Karl Denninger, I would issue a decree saying that all XSRF problems needed to be solved on every site in the 90th percentile on Alexa before anyone was allowed to discuss DNS security.
    • ^
    • v
    I need to know, NEED to know, whether you and I both arrived at a blue passport dude for CAs independently within a month of each other.

    http://blog.johnath.com/index.php/2007/03/21/re...

    (And yes, of course neither of us invented the idea, nor am I implying we're particularly brilliant for invoking it, but nevertheless it sort of caught my eye.)
    • ^
    • v
    Easy. I diagram with a set of network widgety things I drew myself, and the AIGA common pictograms (which you can download as a series of EPS documents). Until Illustrator comes out with a universal binary, I'm stuck with OmniGraffle, and the AIGA pictograms are a stencil in our OmniGraffle install.

    So, you look at the stencil for things that could apply to "security" and you get, uh, "key", "message", "deny sign", "alice and bob", "arrows", and "passport guy". I thought about using "ticket girl" for DNS but that seemed demeaning.

    All joking and self-importance aside: the AIGA pictograms RULE, and they're open-source (really, Alan!). You can get 100x better diagrams tomorrow by:

    1. Using black and white and one or two accent colors.

    2. Never using single-pixel strokes for borders.

    3. Drawing a guide box to represent a plane for all your little icons to live on.

    4. Using the AIGA symbols instead of trying to draw your own stick figures.

    5. Picking one typeface and sticking with it.

    You too can be a bad, wannabe graphic artist!
    • ^
    • v
    Demeaning to ticket girl I mean.
    • ^
    • v
    BTW, Ryan, I said SSH keys, meaning to imply, "people who have gone through the trouble of generating, encrypting, and saving their own personal SSH keys". The numbers may work out better that way.
    • ^
    • v
    Private key auth, then? Yes, I would agree there are more DNS server than that. I don't know if that supports your point as well, though. ;) You know I'm just poking at you for fun's sake, and not as an actual argument against your thesis, right?
    • ^
    • v
    That's too bad. I was kind of hoping that you were. I don't think I'll keep the smart IETF type's attention, and the dumb ones are just going to say, "well, how many RFCs have YOU written?"

    Somebody devil's advocate!
    • ^
    • v
    Hi Tom,

    I think you overlook one potential use of a secure DNS. You say -

    "Securing the DNS protects DNS lookups. But Alice and Bob still need another layer of security."

    You mention that web-of-trust (PGP), CAs (PKI), or key continuity (SSH) all can bootstrap this other layer of security.

    But so could a secure DNS! Consider the potential for putting, say, key fingerprints in DNS to authenticate MTAs and webservers. Or policy information indicating "all emails from this domain are signed".

    I think your argument against this would be that key-management external to DNS is superior due to the end-to-end argument - it's better to have specialized third parties "whose only job is to protect cryptographic secrets" than to burden DNS with this.

    However, when you really look at it, whether the function of providing authenticated (domain-name, public-key) mappings is best provided in DNS or by external 3rd parties is not immediately clear.

    For example, how are these third-parties going to check that someone really is the correct owner of "example.com" before issuing them a certificate? By checking with the domain name infrastructure? In that case, the domain name infrastructure already is the authoritative source for this information, and already has the capability of delivering it efficiently to requestors. So introducing 3rd-party CAs is introducing an additional point of control, security risk, and protocol complexity, and it's not clear that the gains of, say, more centralized private-key security, compensate for that.

    Anyways, certainly CAs can be useful in certifying attributes besides domain-name - e.g., "the holder of this key is a trusted financial institution" or somesuch. And it may be that these other bindings are more important than (domain-name, public-key) bindings.

    However, if authenticated (domain-name, public-key) bindings do have value (and I think they do), then it would seem to me that a secure DNS is a fairly elegant way of providing this. (though I'm not familiar with DNSSEC enough to know whether it's the best way to provide this).

    My 2c, anyways... Cheers.
    • ^
    • v
    Well, I'm not going to discount your position based only on the number of DNS servers vs. keys running around, that's what I was poking fun at.

    I really would like to see secure name resolution, I don't see any good reason for that problem to not be solved eventually.

    I know basically nothing about DNSSEC, so I'm happy to take your word for it that it's a mess. I don't know much about IPSEC either, but it didn't take me long as a VPN administrator to not like it.

    I also have little faith that a big standards committee is going to come up with the "right" solution. So, I can't lobby that the IETF whatever needs to try again. It's like thinking there should be a law, and not trusting the lawmakers to get it right. That's why a lot of people are afraid of Net Neutrality.

    And finally, I'd have to agree in many ways that this isn't the highest priority in the security world. I didn't know there was a limit to the number of efforts, I thought they kind of went in parallel. But yes, there's a limit on our ability to consume new standards.

    So I don't have any good basis for arguing with you. Sorry.

    Next time, though.
    • ^
    • v
    Nice explanation. Unfortunately ssh isn't really that secure. In at leaset 90% of cases, initial ssh connection goes through on the blind assumption that the server isn't already cracked. I've never seen someone actually verify a hostkey (although you can do it through DNS, which is good for organizations more paranoid or organized than us).

    Also, the DNS MitM protection assumes that people are somewhere on the Internet, and can subvert DNS, but cannot subvert sshd or the server OS, in which case they can steal the unencrypted hostkeys and impersonate all they want, or simply eavesdrop without affecting the client-server communicatons at all.
    • ^
    • v
    Trevor has lucidly stated probably the most common case I see made for DNSSEC, which is that once you have DNSSEC, you can build other security applications on top of it. DKIM seems like an example of a practical proposal like this.

    Trevor is totally, 100% correct.

    I simply propose then that we evaluate the -SEC seperately from the DNS-: create a totally seperate hierarchy, run the protocol on different ports, get it the hell out of BIND, and use it solely as a building block. But leave the DNS hostname resolution system alone, because it works well enough now.

    Trevor, I have 3 more detailed posts coming on this, and I'd love to see if the rest of my arguments influence you. =)
    • ^
    • v
    Chris, I'm going to challenge that: I don't verify hostkeys, but I *DO* notice when I suddenly get prompted to accept a new one. SSH does a pretty good job of being loud about this.

    We're pretty paranoid about this, so maybe we're not representative.

    Of course, in the current state of the art, key verification finds its asymptote at browser cert verification, which end-users completely ignore. The same security problem you point out for SSH ALSO occurs if you click through the browser warning. When you discuss getting any better than browser cert verification, you are talking about making SSL/TLS more attractive, and thus (by my reasoning) making DNSSEC LESS attractive.
    • ^
    • v
    Edited this post because I'm removing a word from my vocabulary.

    (Yeah, right. But Dave is going to make me put a dollar in a jar every time I say it!)
    • ^
    • v
    What Tom forgot to mention is that the jar is labeled "Donations for DNSSEC"
    • ^
    • v
    Thomas,

    Yes, SSH warns you when keys change out from under you, but there are 3 major categories of threat here, and this protects you from the uncommon one.

    1) If I subvert DNS and interpose my machine running sshd for yours, hostkeys will warn you. But I've never seen that happen (not that it doesn't, that it's uncommon).

    2) If I break SSH (which used to happen all the time, but has definitely tapered off), I 0wn sshd, and grab its keys. You can't tell you're now talking to a compromised sshd.

    3) If I break into the host OS any other way and get root, I can "upgrade" to my own compromised sshd binary and keep the old keys. We upgrade sshd all the time, retaining keys. No help from hostkeys here.

    3a) If I'm really sneaky, I could grab the hostkeys, and tap port 22. If I have the hostkey, I should be able to eavesdrop on all communications either way by "following along at home" and replicating the host's crypto calculations with its key.
    • ^
    • v
    It's kind of hard for any protocol to help you if you lose your machine to an attacker. My point is, losing entire DNS servers to attackers seems to be the common failure mode for DNS security. Maybe protocols aren't the answer.
    • ^
    • v
    TP

    I think you finally hit the nail on the head. Protocols are generally not the answer because technology cant fix social problems on a large scale. This has been under my fingernails for a while now but I dont think the idea will be generally popular with anyone. The Internet isnt broken and cant be fixed. People are broken. The "fix" tends to come from social structures and laws (and law enforcement).

    In any case its not SSL/TLS or the Verisign protection racket goons which secure your purchases from Amazon or your ebanking; its consumer protection laws which limit your liability for misuse of your credit card or protect you from bank fraud (in the US anyways, the rest of the world is different).

    SSL/TLS/PGP/SSH are due dilligance practices. DNSSEC may or may not be in the future.
    • ^
    • v
    Well, OK, that's fine as far as it goes. But independent of how far technology can go to protect us, DNSSEC is bad technology.
    • ^
    • v
    "bad technology" in the sense that it will cause Godzilla like counter effects or in the sense that there is disagreement on what problem it is intended to solve exactly ?

    But seriously. All hyperbole aside, I see your points but for reasons of practicality, I dont entirely agree with your assertion that authentication should be solved at a higher layer.
    • ^
    • v
    DNS doesn't solve authentication problems for applications. All it does is bind names to IP addresses, or (in a better world), names to little bundles of opaque data.

    And, as I hope my next 2 posts make an adequate case for, I mean "bad" in your first sense. "Really" bad.
    • ^
    • v
    Thomas

    I agree with everything you wrote here. BTW, I love the illustrations too.

    Regards
    • ^
    • v
    (sorry if this has already been discussed but I have not had a chance to read this post in detail)

    For the paranoid among us I found this interesting:

    http://www.theregister.co.uk/2007/04/03/dns_mas...

    I wonder how much truth there is to in and if this is in anyway going to cause the US Gov to try and push DNSSEC forward.
    • ^
    • v
    I'm going to talk a bit about DLV and all the fun that that entails; I don't want to get too far ahead of myself, but, think, "ALTERNATE IANA/IETF FOR DNS".
    • ^
    • v
    my bad. "authentication" wasnt the word to use. should have gone for "authenticity" instead. Still chewing on this overall so may back down again or not.
    • ^
    • v
    Don't! I can use the opposition!
    • ^
    • v
    thomas, thank you for putting it together so nicely, all with the beautiful illustrations. great writing style. gotta show it to mom. shell love it.

    .~.
    • ^
    • v
    @Chris Pepper

    3a) If I’m really sneaky, I could grab the hostkeys, and tap port 22. If I have the hostkey, I should be able to eavesdrop on all communications either way by “following along at home” and replicating the host’s crypto calculations with its key.

    I don't think so - can you also follow the Diffie-Hellman calc?
    • ^
    • v
    Brilliant article! Your diagrams really make it.

    The last point about BIND having many security flaws related to DNSSEC is an interesting one. I use tinydns myself, and was actually looking into DNSSEC after reading about irs.gov implementing it (Slashdot). Apparently tinydns does not support DNSSEC, nor is the author interested in it for a lot of the flaws in the system you pointed out.

    "I'm not going to bother implementing DNSSEC until I see (1) a stable, sensible DNSSEC protocol and (2) a detailed, concrete, credible plan for central DNSSEC deployment. " - http://cr.yp.to/djbdns/forgery.html

    A chicken and egg problem I guess! Anyways, kudos on the informative post.

Trackbacks

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