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

Comments

Re:new security products and services? great.

[i.r.id10t]

Better than generating fear to reduce the rights of your citizens...

Re:new security products and services? great.

[gandhi_2]

Nothing is better than generating fear to reduce the rights of your citizens.

Sincerely,
Both Political Parties.

Optimistic guy

[mtremsal]

Kaminsky is incredibly enthusiastic about DNSSEC. ... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.

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:new security products and services? great.

[headhot]

The Kaminisky bug is real, and its being used out in the wild. This is not a hypothetical academic exercise. DNS needs to be secured. Its not fear mongering, and its not for profit.

Many of these security consultants you speak of are not consultants at all, but experts working on this stuff in their free time for the betterment of the internet.

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.

You just think that way because you haven't been..

[brunes69]

.. hit yet.

Security is a tricky thing. You say security people sell you things "you don't need". But if you wait until you NEED security, it is already too late because you have a breach.

Security is not an ER visit, it is a regular preventative exam with your physician. It is something you have to take a pro-active approach with. Yes, this oten means investing time and money in something that has no immediate ROI. But that is the nature of the problem you are dealing with.

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

Questions from a DNS implementor

[Ex-Linux-Fanboy]

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?

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.