Slashdot Mirror
Kaminsky On DNS Bugs a Year Later and DNSSEC
L3sPau1 writes "Network security researcher Dan Kaminsky has had a year to reflect on the impact of the cache poisoning vulnerability he discovered in the Domain Name System. In the time since, Kaminsky has become an advocate for improving security in DNS, and ultimately, trust on the Internet. One way to do this is with the widespread use of DNSSEC (DNS Security Extensions), which essentially brings PKI to website requests. In this interview, Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services."
There are numerous issues with implementing DNSSEC. The idea has been around for like 14 years now. Also, there are alternatives like DNSCurve which provide more security with considerable ease of deployment.
I haven't deployed DNSSEC yet on my external domains because of cost/complexity. When I looked into it, my options for DNSSEC were:
1) implement BIND and do the key management and rotation from the command line
2) spend $10,000 or so for an appliance from secure64 or nixu
3) spend $1k/month for a hosted DNS provider like neustar or verisign
4) install Win2008R2 RC and use it in producition
I work in a windows shop, so I'll probably go with option 4, but I'm surprised there aren't more set-it-and-forget-it tools out there for DNSSEC deployment. I'm open to recommendations.
OK, since Mr. Kaminsky is following this thread, I figured this would be a good place to open up some questions and a discussion between a DNS implementor and Mr. Kaminsky.
Let me introduce myself: My name is Sam Trenholme and I am the implementor of MaraDNS, a recursive and caching DNS server. Right now, I am in the slow process of re-writing the recursive DNS resolver. While MaraDNS has always been as secure as non-DNSSEC can be against Mr. Kaminsky's bug (DJB knew about the problem back in 1999 and I implemented his solution to randomize both the query ID and the source port back in 2001), I am wondering:
How hard is it to implement DNSSEC in my recursive cache? How many RFCs am I going to have to toil over to understand DNSSEC well enough to implement it? About how long will it take me to code MaraDNS to have full DNSSEC support?
I have a bad feeling that DNSSEC is a monster to implement and that we will not see many independent implementations of it; right now BIND and Unbound appear to be the only DNS servers to support it. DjbDNS doesn't support it, of course, and probably never will. My own MaraDNS and PowerDNS also don't support.
What are your thoughts? Has a reasonable effort been made to make DNSSEC easy to implement?
(This is Dan)
Sure, DNS is a single point of failure with security implications. What else is new? Half my talk last year showed what sort of damage you could do if you could corrupt any DNS name. The root can, today.
It also scales really, amazingly, wonderfully well. See, DNS actually delegates, unlike X.509. That means the root doesn't interact with most people, just a few countries and gTLDs.
So, how many people do you have in your GPG keyring? Few dozen? Few hundred? I spent six months interacting with people over email securely. It added an average of 72 hours of time before work could be done, and often it didn't work. C'mon, this ain't scaling.
(This is Dan)
That's interesting if you're just trying to secure DNS. We have much bigger fish to fry -- fish that require us not trusting the NS at Starbucks.
There already is a standard: SSL. It includes encryption (to secure the content going across the channel against eavesdropping) along with bidirectional authentication (server certificates to verify that you're talking to the server you think you're talking to, as well as the less-commonly-used client certificates to authenticate to the server that you're who you claim to be).
If I were setting up a secure site, it'd be SSL-only. As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account. From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username. And I've long suggested that, for user security, browsers have a feature where the user can associate server certificates with identities and then, by selecting an identity to communicate with, limit the browser to accepting only servers presenting one of the certificates associated with that identity. Have a way for the user to download the server certificate as part of the account setup process and you pretty much eliminate the need for PKI to support the whole thing, self-signed certificates will work since they were gotten directly from the source. You still need verification of both ends, but it's limited to just during the account setup process and isn't an ongoing thing.
(This is Dan)
I actually completely agree with your desire to see trust in the edges. That's what's so interesting about DNSSEC -- DNS, by its very design, is all about getting the core the hell out of the way and delegating, delegating, and delegating some more until the organization that manages the namespace can directly control it.
Indeed, in the ultimate vision of DNSSEC, we have full on validating resolvers in clients. The endpoints themselves can finally - finally! - recognize their peers directly, without having to trust anyone or depend on the admitted messiness of the existing SSL CA infrastructure.
The reality about Active MITM is that it's out there. See the BGP work that came out in tune with my talk -- note that all that still works, today, even with my big fix. Active MITM isn't some theoretical attack, and the reality is that everything is vulnerable to it. An ounce of cryptography is worthless without a metric asston of key management. DNSSEC is just the best way I can see to do it.
Regarding the trust anchor size, the reality is that we have 25 years of it not being a problem. That's the simple truth. Everything I did last year could have been done by a malicious root. It wasn't.
Your corporate/intranet myth is funny, because it strikes at the heart of the problem. You think there's just one corporate/intranet to authenticate. It's literally like you're suggesting, email to other companies is complicated, so lets just do email to our own company. Nice, but not good enough. We need cross organizational trust. We need something to bootstrap it. DNSSEC should be that.
(This is Dan)
There's lots of shysters in every field. Doesn't change the fact that there are problems out there that need fixing. Security is in fact a problem.
In concrete terms, just for my vuln, about 1% of one of Brazil's largest bank's customers had their info taken by my bug. That wasn't fun. And China Netcom got hit pretty hard too, go Google that. Of course, there's a lot of data we're missing, because nobody needs to report. But anecdotally, this was a problem, but not the end of the world. Good! I didn't exactly set out to end the world :)
In terms of what I see fixing, I see a lot of technologies repeatedly sold as "and then you get certificates", and nobody does, because it's just such a cross organizational nightmare to manage. Certs aren't working, and it's holding back auth technology after auth technology. Verizon Business' data says that 60% of vulns aren't implementation flaws -- they're authentication flaws, with passwords at the heart of them.
Why so many passwords? Because they work. Well, DNS works too. Maybe we can use it to make all the better things scale across organizational boundaries.
I don't mind SSH, with its key caching, but what about initial trust? What about the fact that, in the real world, keys change (just like IPs change) and when they do, something needs to say the new content is OK? It'd be nice to have a system that existed independent of any given server, which could (through a *delegated chain that didn't require cross-organizational begging*) assert the validity of new content.
The root servers were there 15 years ago. They'll be there 15 years from now. That's a fantastic foundation to build just what we need.
It's because the PGP keyservers get stale data, and the entire revocation system doesn't work. I have multiple keys in there I can't get rid of, because I don't have a business relationship that lets me identify myself and I don't have the key material to eliminate the key. Go look through the data, it's a mess.
In the end, the keyservers work better than web of trust, but not much better.
(This is Dan)
Hehe. OK, I like you foom. Lets talk.
So the deal is, DNSSEC lets the server at Starbucks cache DNSSEC records for you. So even if it's not doing the validation, it can at least remember the crypto such that each backend host that is doing validation can enjoy the cached records on the shared NS.
You can't do that with DNScurve, since the crypto is link based.
I've been playing with the Curve25519 code lately. It's cool, I have use for it (understatement), and it's a joy to work with. But DNScurve has a design limit, and we need a little more than it can accomplish.