On DNSSEC, Part 1 - It's Not Worthy

It's 2015, and we're still debating if DNSSEC is "worth it". I feel like I'm taking crazy pills.

So let's cut to the quick, shall we? It's not. The latest article begging for a reprieve for the beleaguered protocol extension is a well-meaning but very wrong op-ed that seems to want to get the .se domain signed... I think? I'm not sure.

Firstly, Thomas Ptacek doesn't like DNSSEC. That's OK, according to de facto deployment numbers most people don't. He points out a number of flaws that the extension contains: it's cryptographically weak (true), it's expensive to adopt (in resource hours, not necessarily in currency), and it's architecturally unsound (true for a number of reasons). I like this guy. I might just start to follow him on Twitter.

Now onto the rebuttal, if you are so kind as to call it that. In her op-ed piece "Is DNSSEC Worth the Effort?" non-native English speaker Anne-Marie Eklund Löwinder outlines some of the reasons why DNSSEC doesn't suck. She's wrong. Let's elaborate.

The Internet is a wild place, full of mystery and awe. In the olden days, we had to trust that the IP address and port we were talking to was the one we thought it was, and it was damned near impossible for us to know for sure if it was or not. Man-in-the-middle attacks were not only possible, but easy, sometimes even for SSL-secured endpoints. We were young and stupid and, worst of all, optimistically gullible. Enter Dan Kaminsky.

Dan Kaminsky is not a bad guy, despite the fact he wrote one and a half implementations of something called Paketto Keiretsu and then told us all the code was proof-of-concepty enough for us to worry about our own operating systems and compilers and those implementation details that make things, y'know, work. The last release was in 2002 and that one wouldn't compile no matter how hard I tried to patch it. But I'm not bitter.

So in 2008, Dan found a "fundamental flaw" in the DNS and made a big stink about it. At the time, I worked for a major software corporation and I remember that on the day of his announcement, we nervously funnelled into a conference room to listen to his live web broadcast explaining this packetpocalypse he'd discovered. His multiple-vendor-collaborations-to-push-emergency-hotfixes flaw was just flamboyant marketing on top of a known SNAFU which boils down to "if all your DNS queries have the same source port it's easier to poison the responses". Yawn. This "fundamental" DNS flaw isn't a protocol problem. It's really an implementation choice in BIND and its offshoots and, because we all know that BIND sucks, there's at least one non-paste-eating DNS software package that's been immune to the Kaminsky bug since about 2001. Dan Kaminsky's only real contribution to DNS security to date has been to loudly claim ownership of discovering that the djbdns implementation of dnscache is better software.

I keed, I keed. Sort of. Dan Kaminsky banged a spoon against a pot loudly enough to get the Internet to notice that DNS was insecure, which is good. And then some port-randomization patches got pushed out into production faster than they really ought to have been, and later than they needed to be, and all was right for awhile, but DNS still wasn't "secure". Fortunately, Dan Kaminsky wasn't done yet.

But I digress. We're talking about Anne-Marie Eklund Löwinder and her appeal to the .se domain to adopt DNSSEC. She claims Dan Kaminsky discovered DNS static port exploitability, and then she urges DNS administrators to adopt DNSSEC because it's better than nothing. False. DNSSEC is worse than nothing, because doing nothing won't necessarily knock your domains off the Internet because of an arbitrary expiration date.

Löwinder's real reason for penning her article is to push DANE, tying TLS authentication to DNS, which is itself insecure without someone doing something about DNS first. She argues that if you put your certs in DNS, and sign them with DNSSEC, people can trust your certs. This idea doesn't even work on paper. It just moves the trust problem from your certificate chain to your cache. The reality of the situation is far more complicated than Löwinder lets on, but I don't hold her responsible for a weak proposal. This is a hard problem to solve.

Imagine for a minute if we did the opposite. Imagine if our DNS records were all authenticated with SSL/TLS certificates. You would quickly find yourself wondering which root-level CAs were trustworthy and which weren't. And since you don't have 24 hours a day dedicated to watching for constant reports of cert-signing tomfoolery, you would need to put your faith in all the major technology companies to have your back for you. Your trust is predicated on a private corporation looking out for you, and they only really do that sort of thing when, I don't know, a Chinese root CA spoofs certs in their name. Anyone with enough time and a little capital can become a CA, and then it's a matter of paying OEMs to trust your cert for you. It's not hard to imagine a nation state rolling its own CA and mandating its installation on every device that enters or leaves the country. You might call this scenario encryption, but it's not security. So why are we contemplating putting certs into DNS? There's only one chain in DNSSEC, and you have to trust every link of it, even when one of the links is owned by a nefarious country that hates freedom.

For starters, Löwinder insists that DNSSEC "scale[s] in several different dimensions" and doesn't need "to introduce new code". False. DNSSEC does require new code — quite a lot of it in point of fact — and on top of the new code, you have to maintain your signatures very studiously. With DNSSEC, it is easy to DOS yourself and you need to be very keen and timely to avoid doing exactly such a thing. Neglecting your key renewals makes a DOS guaranteed. She points out that DNSSEC is not designed to prevent DDOSes, which is true. It's so true in fact that DNSSEC is a malicious, connectionless redirection attack's dream come true. She neglects to mention that if you don't have at least a couple people with reminders (and agency) to renew your signing keys, your entire DNS zone will fall off the Internet... by design. The worst enemy for your DNSSEC-configured zone file isn't some foreign enemy state, it's a loyal sysadmin with two weeks of non-transferable vacation and no backup staff.

So let's talk DNSSEC. In theory, it's not a bad protocol. Have a record? Sign the record. Everyone's happy. Here's the problem: they've been trying to get this right for 20 years and they're still nowhere near done. Thomas Ptacek's article points out that they've re-engineered DNSSEC in part or in whole at least half a dozen times, and what they insist today is "DNSSEC for everybody" is only their latest invention. DNSSEC is not, as Löwinder says "a relatively young technology, with 10 years behind it", it's old enough to fucking buy beer. Burning down the shed and contructing a new one on top of the ashes six times over doesn't make it a new shed so much as it makes you a psychopathic architect. DNSSEC can and will sign your records. And that's it. Your records aren't secure, they're just signed. You can verify the signatures, if you hope to hell that a 1024-bit RSA key isn't forgeable by anyone who means you ill will. And if you think 1024 bits for your RSA key is good-enough crypto for today's post-Snowden world, Bill Gates and I have 640KB of RAM to sell you.

I hear what you're saying. "Toby, you idiot," you say. "You're just a DJB acolyte, and since DJB hates DNSSEC, so do you." Yes that's true, to an extent. Thomas Ptacek points out a couple of problems with DNSSEC that aren't entirely true. He claims that it's a government-controlled PKI, which is only 99% true. Remember, DNSSEC is a hierarchical trust chain. .se signs anything that ends in .se, so if the government controls the TLD signing key, then the government de facto controls everything beneath that TLD. Do you think the DNSSEC keys for democracy.kp are secure? How about moses.ir?

As someone I don't remember said, "if encryption isn't end-to-end, it's not encrypted." Ignoring for a minute that DNSSEC doesn't even fucking encrypt anything, you are beholden to every single DNSSEC-using entity from the top down to not screw up their keys in order to keep everything beneath them online. DNSSEC suicide is a real thing. It happens, and it's spectacular. Right, HBO Now? To be honest, HBO Now falling off the Internet wasn't malicious, it was a misconfiguration. Specifically, it was a misconfiguration in a DNS signing extension that makes misconfigurations very easy to do and very harmful to your zone's availability when you do them.

I mentioned that DNSSEC doesn't encrypt your queries. This is by design. The protocol extension implementers decided that encryption was outside the scope of DNSSEC. Perhaps DNSSIGN would've been a better name for it. And signing as DNSSEC calls it is by itself a dodgy prospect. If you're a military commander minding your own business at Cheyenne Mountain and one day you get an unencrypted message saying "I am teh president u should launch all your nucular missals now," and it's signed with a 1024-bit RSA key for president@whitehouse.gov, you'd be right to be skeptical.

Instead of complaining about the darkness, why don't I just light a candle? DNSSEC is hard to get right, but smart people are smart and software is great at fixing these sorts of things. In fact Dan Kaminsky himself wrote the be-all end-all tool a couple years ago to fix everything wrong with DNSSEC! Enter Phreebird!

So Thomas Ptacek complains that DNSSEC is supposed to be "offline only". This just means you take your DNS records into a backroom in a windowless basement underneath the Pentagon, lock the door behind you, sign them, and put the signatures on a web server so no one can figure out how to reproduce what you did in the basement. It's all very James Bond. But online signing in the DNSSEC sphere isn't just possible, Kaminsky claims. It's better! Just install Phreebird in front of your DNS server and have it act as the DNSSEC-enabled server. It gets the queries, queries your real server, than then signs the responses on the fly. Perfect! Only one problem.

I can't compile it. I tried. Phreebird v.1.0.2 was written in 2011. You can still download it if you want. It hasn't been updated since Arcade Fire won Album of the Year. (Or was it a group called "The Suburbs"?) As someone who's gotten relatively far in life for making bizarre software do interesting things, I have to confess I'm not the worst person in the world to try to implement Phreebird as a DNSSEC proxy. I read the directions. I tried using a couple different tool chains. I can't do it. Kaminsky's code is, in a word, atrocious. In three words "Holy Jesus... really?!" I can't make heads or tails of it. It's Paketto Keiretsu all over again. Re-writing it is out of the question. I'm sure it runs on his box, but enterprise-grade it is not. Ordinarily the safety of my network hinging on old software doesn't bother me, except for when the source package is stuck in an early alpha state and is consistently unusable despite all my best efforts to remedy it. Kaminsky himself insists in the README.txt file for Phreebird v1.0.2 that it's "not recommended for production domains" and we should "wait till [version] 1.1".

So online signing is out of the question because the only implementation I can find that purports to fix all of DNSSEC's warts isn't what I'd call "portable" or "usable" or "fit for human consumption" or "ever to be taken out of its lead-lined coffin". What's left?

Well, Löwinder wants you to do a lot of offline signing for the .se records and let your servers be open to DNS amplification attacks and key expiration suicide. I want you to do anything but that.

"Toby, you idiot," you say. "BIND has supported DNSSEC out of the box for a dozen point releases now. Out of the box!" you say. OK, I remember that. ISC's version 9.7 was "DNSSEC for Humans". Two problems. One, my zones aren't in BIND format. That's my fault, and I accept that. Two, I tried it and I still can't get it right. I can tell the difference between real butter and I Can't Believe It's Not Butter, but I can't get a simple 52KB tutorial to work for me. Maybe I'm a simpleton? You're probably much smarter than I am. That's OK, feel free to tweet me a non-trivial explanation of the differences between a key-signing key and a zone-signing key. You have 140 characters... go. I'll wait.

I'm told that Michael W. Lucas has written the be-all, end-all howto book, DNSSEC Mastery. It clocks in at 130 pages and claims to teach you how to figure out how to decipher the BIND configuration quagmire. He repeatedly mentions it's his worst-selling book. I haven't read it. Maybe someone will gift it to me someday. Considering it takes triple-digit pages to get DNSSEC working, I don't feel so bad for not having figured it out from the hodge-podge of online resources I've read up to now. I checked, and Lucas gave an hour-long talk about turning on DNSSEC in BIND for a Michigan Linux/Unix users' group. It's pretty good. I particularly enjoy his anecdote about ISC engineers laughing about how he trusted their zones to always be correctly signed. Lucas is a very learned individual; a master so tenacious and dogged in his research he is one of a precious few technology experts qualified to make other people experts, too. Even he insists you shouldn't touch DNSSEC on any BIND deployment younger than v9.9. I went back in my records and found that this minimally-viable version was announced on 2012-02-29. DNSSEC before this moment is a bad idea because, according to the man who literally wrote the book on the subject, "In the old days you had to sign these [records] by hand.... You do not want to re-sign by hand." It's messy, error-prone, and causes suicidal tendencies, both for you and for your record data. So now you have to fully upgrade or replace any DNS infrastructure you've got if it's been around for more than 3 years. Have fun!

One more time: DNSSEC is convoluted, decades old, and has both negligible use and negligible adoption rates to reflect that. DNS must be secured, there's no disagreement in that. You need to accept that it's time to pick something that will work: DNSCurve for servers and resolvers, and DNSCrypt for clients.

DNSCurve isn't perfect! It requires either NaCl or TweetNaCl. (TweetNaCl is so simple I can get it compile on vanity OSes with minor edits.) DNSCurve doesn't sign like DNSSEC signs! If you ask DNSCurve a question, only you will be able to understand the encrypted answer thanks to a Diffie-Hellman key exchange and the discrete log problem. This makes DNSCurve terrible for contrived situations where you have to prove to Carol that Alice signed something based on what Bob told you. Kaminsky insists this matters. I'd prefer it if you make up your own mind. In theory DH can be generalized to support multiple parties, but this is not supported by the cryptography library that DNSCurve uses. You never ask someone to confirm for you that your bank's website is showing you the right numbers in your account balance and then validate their response. You go to your bank's website and check it yourself. Nothing else makes sense.

Next time: I actually implement DNSSEC. Possibly while drinking.