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."

You obviously have no idea what your talking about

[gubers33]

Do you even know what DNSSEC is? It is nothing he is trying to sell, it is him trying to completely take care of the flaw he found in DNS last summer. A flaw that could have seriously fubared the net if he didn't go through massive patching with internet providers and large companies. So you know, just about all DNSSEC software is opensource, meaning it is free. He isn't a conartist and it is pretty ignorant to call him one, he spent countless hours last summer trying to get the patch out which he didn't make money off of since he released it for free.

Re:new security products and services? great.

[Effugas]

(This is Dan)

No, it really is about securing your assets, instead of trying to deploy yet another magic box that conveniently fails just as you try to get it out of testing.

Re:new security products and services? great.

[headhot]

This is not how the kraminisky bug works. You can intercept and redirect traffic with a properly formed DNS label to a legitimate site.

Re:Optimistic guy

[Effugas]

(This is Dan)

DNSCurve can't achieve end-to-end security while still caching. Without the former, you're trusting the name server at Starbucks not to be malicious. Without the latter, there's a 10x (minimum) increase in DNS traffic and the internet collapses.

There's some really interesting math going on, but operationally DNScurve isn't a good path.

That being said, there are some really interesting things from DNScurve we can integrate into DNSsec without any code mods. Key rollover is a mess in DNSSEC, and it's somewhat unnecessary.

Re:Optimistic guy

[Effugas]

(This is Dan)

Well, I was one of the guys who was wrong (about DNSSEC, anyway) so it doesn't completely match up.

Look, simple question: Do you think the existing system, of X.509 certificates, of SSL CA's, of private PKI's, is at all working? I sure don't. All I see are crappy passwords everywhere, being left as default, getting leaked, being brute forced, etc. Most security technology isn't working.

DNS works well. Seems to me more things should work like it.

Re:Need DNSSEC tools

[Effugas]

(this is dan)

Yeah. This is being worked on. By the time the root is signed, you should have much more at your disposal.

Re:Is DNSSec really needed?

[Effugas]

(This is Dan)

Too many exceptions, like www.facebook.com's low TTL, or CNN's non-response to nonexistent names, etc.

Re:You obviously have no idea what your talking ab

[gubers33]

The DNS cache poisoning attack was used the same week it was put into metasploit on a Verizon DNS in Texas where the attacker was forwarding people to a fake Google page with malware on it. Just one I can recall from when this first came out.

Re:You obviously have no idea what your talking ab

[Effugas]

(This is Dan)

Trust me, I'm raising more hell than you can imagine about the deployment issues of DNSSEC. Here's the truth:

1) You don't actually need to do all that resigning stuff. When best practices involve increasing your costs 100x, something is wrong.
2) You don't actually need to have your signatures expire.
3) You don't actually need that cron job.
4) They fixed that zone walking problem with NSEC3. If you have online keysigning, which I expect everyone to have, you don't even need that.
5) .org is signed. .com is coming, as is the root itself. Things have changed.

Standby. Seriously, this is coming, and it's not going to be miserable by the time you actually need to deploy it.

It's really in DNS - BIND etc. were workarounds

[billstewart]

The flaw is really in DNS - the only authentication field in a DNS request is a 16-bit query id, plus the implicit authentication of a 16-bit port number, and IIRC correctly you could also birthday-attack the query-id. Kaminsky's changes to DNS implementations such as BIND (which was build into djbdns etc. since the beginning) get you a few more bits of protection against an attack, but that just means that DNS is "still pretty weak" as opposed to "really really weak".

And unfortunately, IPv6 DNS is no better - it keeps the same basic header for compatibility, adds some new longer record types, and adds some 128-bit addressing, but the QueryID's still the same old 16 bits.

DNSSEC gets to the root of the problem, with cryptographic signatures on the data. It may be overkill compared to just putting in a 128-bit or 256-bit Query-ID field, but basically it's something that's possible actually get deployed, because it's a set of additional data transported in DNS, not a replacement for DNS's transport protocols. The reasons it wasn't done years ago have a lot to do with the NSA/FBI anti-crypto policies of the 90s, and Verisign's reluctance to do a huge amount of work nobody cares about to protect .com, but we're finally getting the root signed.