-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/772/a-case-against-dnssec-count-2-too-complicated-to-deploy/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
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?
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?
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.
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!
DNSSECbis, somebody should make a t-shirt out of this...
That's quite a coup. That's *added value*.
Oui, bis. Les neuf vies de CCITT!
BTW DNSSECter is the correct term, but nobody has yet raised any issues with DNSSECbis that requires a revision.
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.
The same thing goes for stub resolver libraries supporting TSIG, except the numbers swing much more sharply in my favor.
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).
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.
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.
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.
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?
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 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?)
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.
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?
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.
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.
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.
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.
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.
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.
"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".