A Case Against DNSSEC, Count 2: Too Complicated To Deploy
Thomas Ptacek | April 4th, 2007 | Filed Under: Bitching About Protocols, Uncategorized
1.
Alice wants a.victim.org’s IP. She asks the DNS.
So, a.victim.org is 1.2.3.4. Simple enough? Let’s add a wrinkle:
The question, “what is a.victim.org?”, and the answer, “1.2.3.4!”, are records inside of DNS messages. The DNS —- the whole distributed database, that is —- is made up entirely of these records. The records are keyed by name, type, and class, and contain bundles of data.
A subtlety, which we’ll be returning to —- Alice asks for z.victim.org:
z.victim.org doesn’t exist. Alice doesn’t get a record; she gets an error packet. There’s a difference.
Moving on. Alice didn’t really ask the DNS anything:
Alice’s stub resolver asks her cache to find out about a.victim.com from the victim.com authority servers. The stub is her Mac’s built-in resolver library, which her browser is linked to. The cache is the nameserver SpeakEasy, her ISP, gave her. The authority is “named”, AKA BIND, running on ns.victim.com.
2.
Enough remedial DNS. Back to DNSSEC. Mallory can spoof responses to Alice’s DNS queries. We want to stop her. We use cryptography:
Sign the records (RR’s in the jargon) with a signature based on an RSA keypair. Stick the public key in the DNS where Alice’s cache can find it. Her cache gets a public key attached to victim.com and an “a.victim.com is 1.2.3.4” RR signed under that public key.
If you’re with me so far then, with one important exception, you’ve got the “service model” for DNSSEC —- meaning, what DNSSEC is trying to accomplish. Caches can look at records and tell if they’re valid. Mallory can’t forge records without subverting the keys.
How do we manage and protect those keys? Good question. Let’s introduce some notation:
We can generate and store RSA keypairs. We can fingerprint keys (public keys) by taking a hash or MAC of them, just like SSH and PGP do. And we can use private keys to generate signatures of blobs (or hashes of blobs) of data.
With that in mind:
Ok, breathe.
Alice’s cache ships preconfigured to trust a root key, which basically never changes. Exactly the same way Alice’s browser works with SSL to use Verisign’s CA. Again, let’s call that a “trust anchor”; it’s a secure starting point for DNSSEC queries.
A.VICTIM.ORG. is linked from the root, to ORG, to VICTIM.ORG, containing A.VICTIM.ORG. ORG and VICTIM are delegations (because different people run the roots, ORG, and VICTIM).
In DNSSEC, authentication follows delegations. Sometimes. More on that later.
The root vouches for a key in ORG using a fingerprint record (a Delegation Signer, or DS). Root’s voucher for ORG is signed under root’s key, so Mallory can’t change it: Alice knows the root’s key and now ORG’s key.
Repeat until you get the record you want. This is an authentication chain.
3.
And it’s fine, as far as it goes, though you’ve got to remember that it took something like 13 years to get here.
I’m describing RFC4033 DNSSECbis (bis! Still don’t believe me about the invasion of the OSI-snatchers?) from 2006. The original DNSSEC proposals date back to the early 90’s, when government contractor TIS Labs (Marcus Ranum’s old haunt) convinced the DOD to let them try to secure the DNS.
The DNSSEC attempt preceding RFC4033 put signatures in the wrong place, so that if the key for COM ever got compromised, tens of millions of DNS records would have to be replaced.
That proposal lived, as “the DNSSEC standard” until the end of 2001.
You’re right. It’s a cheap shot to attack the standards process itself for being unstable and untenable. Paul Vixie does a much better job:
dnssec is the worst design-by-committee effort i’ve ever seen, both in terms of how late it is, how fuzzy the goals have been, how often the goals have changed, and how complicated and heavy it is now that it is trying to be all-things-to-all-people.
—- Paul Vixie, about 5 months ago.
(I’m not sure if I agree or disagree with Vixie —- allowing for how unqualified I am to make judgements on the IETF —- but I’m pretty sure that the answer of having him and Jim Reid raise $1.6MM to create a members-only “Shadow IETF” that costs $10k to “vote” was a step in the wrong direction).
But whatever. Back to the protocol, as it exists today. I’ve got something cool to show you. Bear with me, this is going to seem redundant.
4.
Insecure DNS. The host “a” exists, and “z” doesn’t:
Now, secure DNS. The host “a” exists, and “z” doesn’t:
Uh-oh. DNSSEC protects records. “The” DNS. It doesn’t protect DNS packets. Those are just a means to an end. So without magic, we can’t distinguish between a “real” error and a fake one!
That’s sort of a problem. And I sincerely mean “sort of”.
For one thing, Mallory can deny service to Alice and Bob by forging errors. But so what? In a DNSSEC world, Mallory can deny service to the entire Internet from a small botnet by saturating DNS servers with expensive crypto operations.
On the other hand, being able to forge errors also allows Mallory to change the semantic meaning of some DNS zones. The best example is MX, the mail exchanger record: MX tells Sendmail and Exchange where to send your mail. Without an MX, mail goes to your hostname. So Mallory can send mail to the wrong host.
Reasonable people disagree about whether this is all a real problem, but the “consensus” is that DNSSEC needs to solve it. So we get authenticated denial (or “provable non-existence”, PNE, DNSSEC). Check this out:
You take all the RR’s in your zone. You sort them —- which requires its own standard because crypto needs canonicalization —- and them link the names of the RR’s together with another kind of record called an NXT —- errr, sorry, NSEC. An NSEC links two DNS names together, basically asserting “no name comes between these two in the sort”.
Now, when you ask for a record that doesn’t exist, the DNS can inform you of that reliably. You get an unexpectedly wrong NSEC record back from the query. It says, “look, your record falls in between two names linked by an NSEC, in a gap where no name can be”. And that record is signed, “proving” the nonexistence of the name.
And that’s fine, because —- oh wait, you in the back there, you have something to say?
Oh. Crap. You’re right. Bad guys can just walk the NSEC chain to list all the names in your zone. Yeah, that’s pretty much exactly the same thing as allowing zone transfers. I know you’ve had zone transfers blocked since 1998 —- yeah? IETF mailing list guy in the front row? With your hand raised? What’s that?
Well, OK, sure, maybe all DNS names should be public. But IETF guy, the names in your zone read like this:
decmultia.greybeard.com
vax-in-my-basement.greybeard.com
sun-ipx.greybeard.com
symbolics.greybeard.com
slackware.greybeard.com
knights-that-say-nee.greybeard.com
And that guy in the back? His names go something like this:
money0.secretcustomer0.bigbank.com
money0.secretcustomer1.bigbank.com
vulnerable.managementsystem.bigbank.com
payrollsystem.bigbank.com
linux-box.boss-not-supposed-to-know-about.bigbank.com
And let’s not even start talking about the guys who run COM. The RR’s in COM right now are just a couple of tiny NS’s. They keep the whole database resident in memory. But DNSSECbis requires them to set up NSEC records for them, too. And sort them. And, by the way, something I haven’t really pointed out yet about DNSSEC RR’s —- know how I’ve been acting like they look like this:
Well, actually, they look like this:
RSA signatures are kind of painful that way. The COM guys better find bigger boxes.
The IETF has a solution for this problem, which Ben Laurie helped write. It’s not a “standard” yet, and so not really part of DNSSECbis. But it’s funny, and not hard to explain. It’s called NSEC3.
Here’s the idea: turn the NSEC chain into a Unix password file. Make the names into salted crypt(3)-style hashes. You can prove an NSEC3 record matches what you were looking for or not, but you can’t turn the NSEC chain back into the zone dump. At least not without crack(8).
I have misgivings about this idea. You can scale password files up with compute using adaptive hashing, because people don’t log in to their computers very often —- but people use the DNS all the time, so you can’t make a lookup step take 5 seconds.
Fortunately, there’s another IETF solution to the problem. It’s called “minimum coverage NSEC”, also known as “whitelies”, involves the servers forging NSEC records to trick people trying to dump the zone, seems to require on-demand signing of RR’s (a no-no —- your privkeys are supposed to be in a vault in Tuscon), and nobody is ever going to deploy any of this so let’s move on.
At this point I’m reminded of a classic from the Western canon:
Scientist
Mr. Simpson, we don’t play God here.
Homer
What? You do nothing BUT play God. And I think your Octoparrot would agree.
Octoparrot
Squawk! Polly shouldn’t be!
One more wrinkle. This looks like a total non-starter for the COM guys. So they were demanding an extension, informally known as “opt-in”, which lets them mark whole stretches of the COM RR space as insecure so they don’t have to run their name servers on Beowulf clusters just to let 10 guys mess with DNSSECbis.
But none of these things are in the “standard”. Which is “finished” and we’re supposed to deploy. NSEC? NSEC3? Whitelies? Opt-In? Or can we just do away with authenticated denial altogether and go with “signing only” DNSSECbis?
5.
5.0.
Another issue. DNSSECbis protects RR’s, which are like the nuclei of DNSSEC cells. But the cell walls are still fragile, and other things besides normal DNS rely on them —- for instance, DNS dynamic update, which is its own debacle. Want secure dynamic update? That’s a different standard, either called TSIG (which secures DNS the same way DESLogin secured Telnet), or SIG(0), which uses public keys. These are different standards than DNSSEC.
5.1.
Another issue, which may have been obvious:
Alice’s stub resolver library is not going to support DNSSECbis any time soon (note to my Apple and Microsoft readers who spend money to audit their OS and runtime code: Alice’s stub resolver library is not going to support DNSSECbis any time soon. Get it?).
So DNSSECbis doesn’t protect the “last mile” between Alice and her ISP. “But that’s OK, that last mile is behind a firewall!”
5.2.
Another issue: nobody knows when or where or how or who or why the roots are going to be signed and who will own the key. Without dignifying this “Homeland Security wants the root signing key” controversey, let’s acknowledge that the dream of a solid authentication chain running from a.victim.com all the way back through COM to the root isn’t happening anytime soon.
That’s OK. The ISC, authors of BIND, have set up a parallel ICANN for DNSSEC, and a protocol extension to match it. If the ICANN/IANA roots won’t secure “a.victim.org”, DLV will secure “a.victim.org.dlv.isc.org” for you. And all you have to do is trust yet another server, this time run by the ISC. And also accept DLV as part of the DNSSECbis standard, which it isn’t, yet.
Having fun yet? Anyone want to lay odds on DNSSECbisbis (or whatever the CCITT folks do after “bis”) happening?
6.
Which, thankfully, brings me to the last part of my argument.
Have you ever set up an SSL certificate?
Have you ever set up a zone with an AXFR secondary in BIND?
These are not two great tastes that go together. But it gets worse. It always does. Because here’s something else that you’ve probably done: you’ve visited a totally legitimate HTTPS website that had an expired or transiently broken SSL cert.
When that happens, you get a click-through warning, which you dutifully ignore. That’s a part of the Internet that the DNSSEC people don’t like. And I feel their pain. But.
When a browser sees an invalid SSL certificate, it has the option of popping up a warning dialog that you can ignore. Now, this is what DNS lookup code looks like in your applications now:
if(!(hp = gethostbyname("a.victim.com")))
fatality();
And, this is what DNS lookup code looks like in your application after DNSSEC:
if(!(hp = gethostbyname("a.victim.com")))
fatality();
And, “fatality” is what you get if any piece of this DNSSEC puzzle fails. All the signatures on all those records out there? They expire and need to be renewed. And they have be kept in sync across the whole system. And they have to be configured, by tens of thousands of people of wildly differing skill levels.
That’s because the DNS interfaces on every host on the Internet have no good way of signalling failure. In fact, because DNSSECbis won’t extend down the “last mile”, like I mentioned, the protocol won’t have a good way of signalling failure. Which means that all the transient glitches you get with SSL, which is a vastly simpler and smaller system, are total failures in DNS.
Still a believer? There’s more to come.
Thomas Ptacek
April 4th, 2007 11:54 pmBTW, 5 people in the world that know lots about DNSSEC: please don’t complain that I missed KSK’s and ZSKs in my DS-scheme explanation.
Ryan Russell
April 5th, 2007 1:07 amOK, let me make myself look as ignorant as I am.
So, we’re caching lookup failures now? When I send out my signed chunk that says I have only a.thievco.com and c.thievco.com, what happens when I want to add b.thievco.com? I have to wait for cache expirations now?
And to overexplain 5.1 for me… if my Mac resolver will happily take a bare nxdomain packet… that means it’s also going to take a bare 1.2.3.4, even if the signed real answer of 5.6.7.8 is on its way?
Do resolvers have a way to demand a signed answer? Do they have a way to know that they are supposed to be getting signed answers? I’m talking DNSSEC-aware resolvers, now…
If I ever turn on DNSSEC in my DNS server, can I ever turn it off? How do the resolvers know I’ve given up, and have gone back to plain DNS? How do they know I haven’t, and someone is playing games?
How about key revocation, for when my DNS server is compromised because of the new untested crypto code?
Thomas Ptacek
April 5th, 2007 1:16 amI’m hoping never to have to re-read 4033 again, but if I remember correctly and understood 7 years of namedropper list bickering properly, the idea is that “proved nonexistence” is negatively cached the same way NXDOMAIN is. In the DLV standard they spend a lot of time talking about “aggressively” caching it.
As for 5.1: you are correct, sir.
There is *another* standard, called TSIG, which gives you a *symmetrically-keyed transport* to talk to your cache with — that’s right, it’s a completely new and different security model — but that doesn’t matter because you’d have to be batshit crazy to implement any of this in your runtime libraries. So basically yeah DNSSEC protects everything on the Internet except the servers and the desktops.
Resolvers CAN do their own checking, if they implement a full “security-aware resolver” algorithm. They set a bit in the packet saying, “Mr. Caching Resolver, Please Don’t Bother Screening Responses For Me Because I’ll Check Them Myself”. But this involves your resolver library doing its own recursive lookups and it’s own caching (because holy do you ever need to cache now that you’ve tripled the number of records between you and the root and blew the packets up by an order of magnitude).
There’s a bit in the DNS header saying “do secure stuff”, so I guess you can turn it on and off.
There’s “key revocation” in the sense that you can change the ZSK or KSK keys in your domain, tell your parent about it, and then hide under your table during the remaining cacheable lifetime of the DNS records and their RRSIG signatures.
HOW DO YOU NOT LOVE THIS PROTOCOL?
Ryan Russell
April 5th, 2007 1:36 amAwesome. You’ll be finding vulns for *years*.
Right, so 5.1… The servers will all be doing 100 times as much work to do the same thing they do now. And then every single hotel or coffee shop I ever go to is still going to spoof DNS to point at their “click here to give me $10″ web page.
I think I might be getting a sense of the downsides you’re hinting at.
Thomas Ptacek
April 5th, 2007 1:40 amJust 2 more novellas to write and I’ll rest my case.
Joe
April 5th, 2007 1:48 amNice graphics. What did you use to generate them?
Thomas Ptacek
April 5th, 2007 1:53 amThis time, I set up a 20″x20″ custom document in OmniGraffle and drew all the graphics side-by-side on the same page.
I used some of the same AIGA pictograms from last time, but I also raided the Apple dingbat fonts to get things like the check mark and the pen icon and the recycling sign.
Everything else is just “black and white and accent colors, consistent palette, consistent typeface, no 1px borders”. You too can be a frustrated bad wannabe graphic artist and IETF griefer!
Thomas Ptacek
April 5th, 2007 1:54 amThe secret to getting graphics out of any Mac application and onto a blog post: don’t “Export” them or “Save” them or “Print” them or anything silly like that; use CMD-OPT-4 to cut-select-screenshot them into little PNGs, which will look *exactly* like they do on the screen, size and all.
d
April 5th, 2007 2:03 amwow. just… wow. i hadn’t been following DNSSEC for years, thanks for the fantastic writeup. reminds me of Rohit Khare’s old IEEE column on application protocol design, “Seventh Heaven” - only this looks like sheer hell.
DNSSECbis, somebody should make a t-shirt out of this…
Tom Ferris
April 5th, 2007 2:41 amnice lloonngg write up..
Links » The Joy of DNSSECs
April 5th, 2007 6:34 am[…] Matasano Chargen have an amusing writeup of DNSSEC, complete with pretty pictures. I need to learn to make OmniGraffle do that! […]
wrc
April 5th, 2007 9:26 amThe really funny part of DNSSEC is that it is an overcomplicated, rollicking trainwreck of a protocol that somehow avoids encoding the whole mess in ASN.1.
That’s quite a coup. That’s *added value*.
Oui, bis. Les neuf vies de CCITT!
Thomas Ptacek
April 5th, 2007 9:33 amYes, they *invented their own key format*.
Jay Daley
April 5th, 2007 11:45 amThat’s an excellent write up of DNSSEC. I told you it isn’t that scary when you take a proper look. Have you thought of updating the Wikipedia page? Your explanation is much better.
BTW DNSSECter is the correct term, but nobody has yet raised any issues with DNSSECbis that requires a revision.
Thomas Ptacek
April 5th, 2007 12:07 pmJay, you look at this and think, “not scary”?
Can I summarize the scary bits and get your comment?
As the standard exists now:
- DNSSECbis forces all secure zones to allow zone transfers.
- DNSSECbis forces COM to set up a vanilla NSEC chain for millions of zones, each with signatures.
- DNSSECbis doesn’t itself standardize a way for resolver libraries on Unix or Windows to perform secure lookups.
- DNSSECbis provides no key revocation mechanism.
- The best current known deployment proposal for DNSSECbis sets up an alternate ICANN rooted at the ISC and requires everyone to trust Paul Vixie.
and, finally:
- DNSSECbis takes the innocuous, transient failures we deal with in SSL today, increases their frequency by an order of magnitude, and turns them into complete service outages.
For each of those points, I’d be appreciate of an argument that says either:
- I’ve misread the situation and am wrong about the implications of DNSSECbis, and here’s why
or:
- What I’m perceiving as “scary” is really irrational and won’t cause real operational problems.
I don’t want to pretend like I’ve gotten any kind of “consensus response” on this post yet, because it’s just a few hours old, but I’ll say that so far you’re the first person to come back to me with “this is no big deal”. Some of the informal responses I’ve gotten have come from namedroppers people.
Thomas Ptacek
April 5th, 2007 12:09 pmAlso, an unfair point that I didn’t make in the article: there are only two well-known, battle-tested implementations of DNSSECbis — BIND and NLnet’s — and the overwhelming majority of implementations (BIND4, BIND8, djbdns, and Microsoft DNS) won’t support it.
The same thing goes for stub resolver libraries supporting TSIG, except the numbers swing much more sharply in my favor.
Matt
April 5th, 2007 3:07 pmFantastic series so far, and I’m looking forward to the last two articles. I’m going to send links to a couple of my professors (one who is, in fact, an author of several RFCs, and had some pointed things to say about DNSSEC in class last quarter).
One minor quibble:
Haven’t the responsible parties gone to some length to avoid forcing DNS servers to do crypto online? Also, given that DNS has proven rather robust against vanilla DDoS (anycast at the roots + caching everywhere), it seems plausible that DNSSEC would be robust against even DDoS Now With Bonus Crypto(tm).
Thomas Ptacek
April 5th, 2007 3:43 pmNo! What they’ve avoided — FOR THE MOST PART — is the need to SIGN things on-line. The reason for that, again, is so that you can keep sensitive privkeys in a vault in the foothills of Virginia.
But the whole of DNSSEC depends on public key crypto; EVERY RR is verified with a public key (RSA+SHA in the common case). And there are lots of RR’s implicated in a normal recursive DNS lookup, and EVEN MORE in DNSSEC.
DNSSEC definitely does NOT avoid expensive crypto operations.
Thomas Ptacek
April 5th, 2007 3:43 pm(”For the most part” because some of the defenses against turning NSEC into unauthorized zone transfers rely on being able to create and sign ephemeral records).
Matt
April 5th, 2007 4:31 pmOK, I was thinking about an attack on the authoritative servers, but it sounds like you’re talking about an attack on, say, a few hundred (thousand?) major ISPs’ nameservers. Yes, that stings.
trevp
April 5th, 2007 6:02 pmTom,
good presentation of various potholes & challenges… they may be unavoidable… the track record of internet-scale key management isn’t very good.
However, isn’t that a reason to *encourage* experiments, see what sticks, and try to learn what we can and enlarge our toolbox?
Perhaps a question you could tackle later on: Is a secure DNS a fatally flawed *concept*, or could you imagine a DNSSEC you approved of?
For me, the DNSSEC-SO draft looks appealing:
1) drop the “provable non-existence” req’t. This solves your problems with enumeration & online signing keys.
2) allow off-tree signing, so that end-resolvers can make their own trust decisions without a global root (I think you slight this approach in the DLV case by saying “all you have to do is trust another server”… you don’t *have* to trust another server…. you *get* to trust whichever server you choose, which defuses the politics of a single root and the limits of a one-size-fits-internet security policy)
3) assume validation happens at end resolver - intermediate resolvers shouldn’t, in general, be making assumptions about end-resolver trust policy.
Imagine this used for SPF, DKIM, CERT RRs, SRV RRs pointing to keyservers, etc… cool, no? (you’ll probably say no, but what else do you got - CAs issuing certs based on an email to the whois contact? PGP WoT? It’s hard times all around…)
Anyways, good stuff. Looking forward to next one.
Jay Daley
April 5th, 2007 6:20 pm> - DNSSECbis forces all secure zones to allow zone transfers.
Solved by NSEC3
> - DNSSECbis forces COM to set up a vanilla NSEC chain for millions of zones, each with signatures.
Solved by NSEC3
> - DNSSECbis doesn’t itself standardize a way for resolver libraries on Unix or Windows to perform secure lookups.
I’m not sure I understand what you mean but I’ll try to answer.
For most applications all they do is call gethostbyname and get a response. What matters is under what circumstances they get that response:
* The current state of resolvers is that they accept any response that looks correct and pass it on.
* The state we want to end up in where only secure, validated responses are passed on (as the result to gethostbyname without any additions to the API).
* There are likely to be some intermediate states where some combination of unsigned or secure responses are passed on
But all of these will be configured in the OS by the syadmins not by application developers (in most cases)
> - DNSSECbis provides no key revocation mechanism.
I need to think about this more, but here is the top-of-my-head answer. Because of the way DNS works a key revocation mechanism is out of scope. Authoritative servers only respond to queries, they do not send out data without being asked. Once a response has been sent there is no way to revoke it if the key is later compromised. The only thing you can do is send new responses signed with a new key. Now, you might ask why a key cannot be kept in the zone and marked as revoked - well the simple answer is that nobody is going to ask for it if you have now signed all your records with another key. So nobody is ever going to find out it is revoked.
Just to reiterate, this is about DNS, not DNSSEC. DNS is an odd beast and the subtleties of the way it works can have some strange implications.
> - The best current known deployment proposal for DNSSECbis sets up an alternate ICANN rooted at the ISC and requires everyone to trust Paul Vixie.
That question is about politics not technology. The best deployment proposal is for IANA to sign the root. DLV is a poor substitute for that. Unfortunately it is politics that is preventing the root from being signed. This is the biggest single problem affecting DNSSEC.
> - DNSSECbis takes the innocuous, transient failures we deal with in SSL today, increases their frequency by an order of magnitude, and turns them into complete service outages.
The difference between SSL and DNSSEC is that you only need to bootstrap DNSSEC once with the root keys but then a resolver will be able to rollover keys and maintain currency (OK so the rollover mechanism is still being finalised). With SSL the trust anchor provisioning is through a different channel and subject to a high barrier to entry. That leads lots of people to have certs without a CA signature. On the issues of expired certs again this is different. In SSL it is down to sysadmins to replace certs when they expire, again a different provisioning mechanism. However most DNSSEC-aware authoritative servers are likely to have all the code necessary for automatic resigning and key rollover and of course switching ZSKs in DNSSEC is in-band (i.e. through the same mechanism as DNS, not a separate channel).
> I don’t want to pretend like I’ve gotten any kind of “consensus response” on this post yet, because it’s just a few hours old, but I’ll say that so far you’re the first person to come back to me with “this is no big deal”. Some of the informal responses I’ve gotten have come from namedroppers people.
I guess that because I am relatively new to DNSSEC (only a few years) and I didn’t experience the pain of the many dead-ends this protocol took on the way to where we are now, I can only comment on the technology as I see it now, which looks pretty good to me. From reading your article above it looks as though your opinion on DNSSEC is also influenced by the path it took to get here, when I don’t see any need for you do to do that.
Thomas Ptacek
April 5th, 2007 6:47 pmI think MSJ’s Signature-Only is pretty clearly a better design.
Vixie seems to imply that SO leaves open the major data-driven hole in the DNS (poisoned NS/A chains) — because there’s no way to tell if those RR’s have or don’t have RRSIGs? But Vixie also seems to imply that the major reason not to consider SO is that it’s “too late” — we’re already at DNSSECter and SO puts us at — what, DNSSECapres?
I think having a global distributed key infrastructure sounds great. I just wish they’d stick it on a different port and keep their chocolate (or lye, as the case may be) out of everyone else’s peanut butter. For each of the problems you mentioned, isn’t there another solution that can rely on TLS?
Thomas Ptacek
April 5th, 2007 6:49 pmJay that’s a thoughtful response, which I haven’t earned. Thanks. I’ll do you the courtesy of thinking about it before I reply. =)
erich
April 5th, 2007 7:36 pmWhat about replay attacks?
So assuming a domain was just registered. I query for wwa.domain.tld, so I’ll probably get a record saying “there is no entry between mail.domain.tld and http://www.domain.tld“.
Now I store this record, and whenever I want to annoy that company (which has added ssl.domain.tld or secure.domain.tld or mx1.domain.tld), I replay this record to anybody who does or doesn’t care?
Or do the signatures include a timestamp (which in turn means they need to be calculated for each request, and that can eventually mean I could build a huge database and hope for a hash collission?)
Chris_B
April 5th, 2007 11:33 pmAlot more food on the plate now. I’m starting to see other practical issues with implementation and maintenance in terms of bigcorp.com but should talk to a few people before opening my mouth in public.
One question being, how well can a DNSSEC server work if its cut off from the outside world?
TIS Labs eh? Figures. Same guys who sold the whole Key Escrow thing to Slick “Seegar” Willy & The Clintonistas.
Oh and TP, you werent supposed to reveal the secret of Cmd Opt 4. I’m going to have your Amateur Designer license revoked.
Thomas Ptacek
April 6th, 2007 1:14 amSo, Jay, help me understand some stuff.
1. NSEC3 isn’t DNSSECbis. In fact, it isn’t even an RFC, let alone a standard. NSEC3 seems to “compete” with whitelies, another not-a-standard. There is, from what I can tell, one C implementation of NSEC3 in the world. Are you defending DNSSECter, or DNSSECapres, or what, and when will it exist for me to critique unfairly?
2. Since the last NSEC3 workshop, concerns have been brought up on namedroppers and elsewhere that with reasonable parameters, NSEC3 validation consumes more CPU than RSA. NSEC3 has different scaling properties than password hashing. Why should we assume NSEC3 will both scale and remain secure? The motivator for NSEC3 was, “you can’t even deploy DNSSEC in the European Union because of privacy laws”.
3. How exactly does NSEC3 solve the problem of the COM registry having to sign, sort, and chain together all the COM domains? I’m sure there’s and answer and I’m not understanding something. There is, as Paul Vixie once pointed out, a lot that I don’t understand.
4. When I said “resolver libraries”, I meant, “stub resolvers”, as in, “the resolvers on almost every machine on the Internet”, most of which won’t support DNSSECanything. Are we really going to roll out DNSSECbis AND TSIG? When you say, “sysadmins will configure this”, remember that most stub resolvers don’t live on machines that have admins.
5. When I compare transient failures in TLS to service outages in DNSSEC, I’m acknowledging that even when certs are unsigned in TLS, people can still use web applications — in fact, in virtually every case, they also get confidentiality and message integrity those sessions. But in the DNSSEC case, key problems — which, again, are common, as we’ve discovered with TLS — make servers unreachable. Is this not a compelling argument?
Jay Daley
April 6th, 2007 4:39 pmOn NSEC3 (Yes I’m an advocate of NSEC3):
NSEC3 is an add-on to DNSSEC. It doesn’t change the core protocol and it doesn’t obsolete any part of it, but is an alternative to NSEC.
NSEC3 includes opt-in as a core part of it, which solves the deployment problem of .com and others with large zones.
There are some circumstances where NSEC is suitable and some where NSEC3 is more suitable. To give you an example, in .uk we have almost all the delegations at the third level under co.uk, org.uk, etc. The .uk zone is small, rarely changes and we actually leave it open to AXFR. This means that we would be quite happy to sign the it with NSEC. co.uk however is a different matter, we do not leave it open for AXFR, it changes frequently and is large. So signing with NSEC3, using opt-in, is much better.
Yes, online signing (white lies) is another way of avoiding some of the issues of NSEC. However it does so by placing your key in a very vulnerable place (on a production server) and exposes you by having to generate all those sigs. I don’t like it.
Finally on NSEC3, the scaling is controlled by the use of opt-in. Yes there are potential issues with the use of iterations but sensible server design can prevent this.
On stub resolvers:
In the enterprise, Windows PCs are centrally managed. The central sysadmins control DNS, IP addressing and the contents of the registry all by remote configuration. It is those people who will decide how the last mile of DNSSEC works.
For most home PCs these are configured according to some instructions sent by the ISP. Almost central configuration but much less predictable. It will just take longer for that route that’s all.
But at some point we will get a new version of Windows, Linux etc where DNSSEC is on by default and only secure and validated responses are passed on. Might be a few years though.
TSIG is a distraction. That has nothing to do with DNSSEC. But as it happens, yes I confidently expect Microsoft to implement DNSSEC for their desktop OS. DNSSEC that stops at the caching resolver is not good enough.
On web apps:
Web sessions are interactive. When you receive an unsigned cert then you lose proof of ownership but you can make a personal decision on whether or not to proceed. You can decide if you have typed in the URL correctly.
DNS is not interactive and someone cannot easily decide “did I ask for the correct DNS lookup there, should I trust this anyway?”. So you can’t expect people to make the choice on giving up proof of ownership as they can with web browsing. That means that DNSSEC has to have the chain of trust.
As I explained previously, most of the reasons why you end up with unsigned certs (including having to pay for them) do not apply in DNSSEC.
Wouter Veugelen blog » A Case Against DNSSEC
April 6th, 2007 4:55 pm[…] A Case Against DNSSEC, Count 2: Too Complicated To Deploy […]
Jay Daley
April 6th, 2007 4:58 pmI haven’t thought this through fully but here goes.
Replay attacks of signed NXDOMAIN messages might be a problem, but I think that once again the unusual way that DNS works comes to the rescue.
No, the responses are not timestamped, but the sigs are and they expire. So a replay attack is only possible for a fixed period of time using any particular message.
But what we have to remember though is that the subject of the attack may have already received the message and cached it, in normal DNS operation. So what is important is the relationship between the message TTL and the sig TTL. Tune these two correctly and you can greatly diminish the impact of a replay attack.
Having said that, just take a step back and think what a replay attack of this nature is doing. It is not taking an existing domain off the air. All it is doing is temporarily holding up the provable existence of a new domain. This is not that profitable an attack vector. With the vagaries of registry provisioning systems and DNS propagation the introduction of a new domain is always a bit of a stutter.
Thomas Ptacek
April 6th, 2007 5:06 pm1.
The NSEC3/opt-in thing answers my question. Thanks for clarifying. I buy that the opt-out bit in NSEC3 addresses the COM scalability problem.
2.
Regarding stub resolvers: I’ll concede to you a world in which ISPs and enterprises can coerce the majority of their customers into using DNSSEC-secured resolvers. I think my post concedes that too. But the “last mile” between the cache and the stub resolver is still insecure; anyone who can spoof packets and guess ports and query-IDs can spoof the DNS. That’s *exactly where we are today*.
I found the argument that “that’s ok, those people are all behind firewalls” particularly amusing. The overwhelming majority of vulnerability hosts, and in particular the vulnerable hosts that we’re concerned about protecting (home users who are vulnerable to phishing attacks) AREN’T behind firewalls.
Again: even if I concede that DNSSEC helps secure the links between caches and authorities, and that it helps prevent lookup-chain poisoning; by a count of vulnerable machines, DNSSEC is solving a tiny, tiny fraction of the DNS spoofing problem (and NONE of the real operational problem, which is coordinated DOS) at enormous expense!
3.
The idea that TSIG has nothing to do with DNSSEC isn’t a distraction. It’s part of my point. DNSSEC is so complicated that securing the most active, commonly-used DNS transport required a totally different standard, currently a standards-track RFC, that nobody uses.
4.
We help companies like Microsoft secure their code. We make recommendations to them about which features should scare them and which shouldn’t. Right now, I would point them to the security track record of BIND, particularly with DNSSEC-related records, and say “stay the hell away as long as you possibly can, because you are going to get burned on this.” I hope resolvers on common OS’s DO NOT enable DNSSEC and am strongly recommending that they don’t.
5.
Regarding web apps, you’re kind of making my point for me. DNS isn’t interactive. DNSSEC failures break web applications in situations that TLS currently handles.
Jay Daley
April 6th, 2007 5:35 pmWe appear to have different visions of how the last mile should work.
My view is that the client OS should set the DO bit and do DNSSEC itself. Secure validation should not stop at the caching resolver, but the stub resolver should beDNSSEC-aware and the last secure link in the chain.
I didn’t say that firewalls remove the need for this last mile validation, because I don’t agree with it. It doesn’t matter how good the security in the enterprise is, the secure validation must be done on the client OS.
TSIG is designed for different participants, because it is a shared secret scheme so there is already the trust relationship. That is why it is used primarily for DDNS, IXFR and AXFR, which DNSSEC does not secure.
Thomas Ptacek
April 6th, 2007 6:12 pmI respect that view about the “last mile” not being secured by DNSSECbis. What do you think about Signature Only DNSSEC?
For the reasons I outlined in the last post, I think DNSSEC is just a bad idea all around; applications do a better job of solving security problems than infrastructure does. As a concrete example: having Windows and OSX do full DNSSEC makes the DNS resolver code in the clients much more complex, and therefore much more likely to harbor vulnerabilities.
Who cares if the DNS is more secure if the code to implement it gives attackers control of everyone’s machines? I’d rather work another 10 years on an Internet without secure DNS than see one more SQL Slammer.
Thomas Ptacek
April 6th, 2007 6:21 pmAlso: unless everyone runs a cache on their local machine, isn’t local DNSSEC validation a nonstarter?
Jay Daley
April 7th, 2007 6:34 pmTo be clear, I want DNSSEC validation done on the desktop. Only a secure last mile is a fully secure chain.
As far as I know all local resolvers, including those on Windows, have a cache. So all that we need added is DNSSEC capability and the last mile is secured.
As I’ve said before I don’t think DNSSEC is all that complicated so this is not too difficult to achieve.
I take your general point about complexity though. But I think there are lots of better candidate for simplification than DNSSEC, such as anything involving SOAP.
Chris_B
April 8th, 2007 8:27 pmHaving read all this, including Jay Daley’s “secure last mile” bit reminds me once again of the analogy of using an armored car to deliver messages between cardboard hobo shacks.
LonerVamp
April 9th, 2007 11:22 amYes, while I won’t even begin to pretend I understood half of this talk and the ensuing comment threads (I try!), I still fail to see the need to add this much cost to solve the DNS problem… Simply talking about key management and keys is going to remind too many people about high-cost, failed projects involving keys, while glazing the eyes of everyone else.
Bill
April 10th, 2007 12:08 pmhttp://www.theregister.co.uk/2007/04/03/dns_master_key_controversy/
“The US Department of Homeland Security is pushing to get hold of the master keys for a proposed revision of the internet’s domain name system.”
This article was published a week ago today on The Register. I didn’t catch it then, and I don’t think the link has surfaced in either of the comment threads on Thomas’s ardent crusade against DNSSEC.
If anything, it’s worth reading just for the byline of “All your DNS lookups are belong to US”.
Richard Huffman
April 20th, 2007 5:14 pmI’m puzzled as how an opt-in/opt-out choice solves the scalability problem, since the only way to secure the authentication chain is for all future stub resolvers to be migrating to DNSSEC[n]. So what I imagine happening is a nice friendly error message warning users that the authenticity of the site they’re visiting can not be verified being thrown out by the stub resolver upon connecting to an opt-out domain. Do I not understand how the opt-in opt-out situation will work?
Thomas Ptacek
April 20th, 2007 5:34 pmThe point is, plenty (meaning, “the overwhelming majority”) of .COM domain owners don’t care about DNSSEC; the .COM people don’t want to pay a 10x in-core storage penalty for maintaining signatures on their records.
Juxtaposition
May 29th, 2007 11:58 pmDNSSEC explained and criticized
Ouch.Matasano Chargen » A Case Against DNSSEC, Count 2: Too Complicated To Deploy dnssec is the worst design-by-committee effort i’ve…
Links » RFC 5155
March 11th, 2008 6:43 am[…] Chargen explain why this RFC is needed, complete with pretty pictures. They don’t say why its complicated, though. The central […]
Leave a reply