Kaminsky Bug Options Include "Do Nothing," Says IETF

netbuzz writes "Meeting in Minneapolis this week, the Internet engineering community is debating whether to aggressively fashion and apply fixes for the so-called Kaminsky bug in the DNS discovered this summer, or to simply let its threat stand as motivation for all to move with greater speed toward DNSSEC, which is considered the best long-term security solution. Problem with the latter approach is that DNSSEC has been in the works for a decade already, no one is confident it will be universally embraced, and the Kaminsky flaw is causing real problems today.

Comments

So what powers does the IETF have on this?

[Vellmont]

I'm trying to figure out exactly what they're deciding. Yes, I understand it's a discussion about "upgrade to DNSSEC" vs. "implement the hacks". But these guys don't control the internet, and my understanding is they only make "recommendations", which nobody is obliged to follow.

So exactly what exactly are these guys debating about "doing"? Is it really just "recommend DNSSEC" or "recommend the hack"?

Re:So what powers does the IETF have on this?

[JCSoRocks]

On top of that, recommending DNSSEC is starting to sound like recommending that everyone start playing Duke Nukem Forever.

No one likes patching sinking ships but it's better than nothing. Doing nothing and waiting for DNSSEC are nearly the same thing.

Re:So what powers does the IETF have on this?

[mrsbrisby]

If so, inventing some other more secure upgrade to DNS really is a waste of time (unless it's somehow easier to adopt than DNSSEC).

Like for example, dnscurve, which requires very little effort to set up, is actually backwards compatible with DNS, protects against some denial of service attacks (instead of creating them), and oh yeah doesn't require the cooperation of the parent zone.

DNSSEC is a joke. A bad bad joke. Replacing DNS with something not-DNS isn't any better an idea than replacing the Internet with something not-Internet. It's 2008 and there are still sites without MX records. You simply cannot "replace" all of the Internets all at once. It just doesn't work. Someone needs to take away the ISC's talking privileges until they stop fucking things up.

Re:So what powers does the IETF have on this?

[mellon]

When you read this article, I think it's virtually impossible to come away with a correct impression - this is a really bad case of the game of telephone.

The situation is that the major DNS vendors have all produced patches to their DNS server software that increases the entropy of the queries these servers send, so that now instead of spoofing being something that can be done with the relatively trivial hack Dan came up with, you now have to pretty much bludgeon the network to death for about 24 hours to get a successful attack.

So it's still possible to get a successful attack, but it's much, much harder. And if you do such an attack, it's really easy to detect.

So what the IETF is now discussing is how to exclude even the 24-hour bludgeoning attack. This is very different than what we were discussing in secret before the Kaminsky attack was revealed to the public. So "do nothing" really isn't as bad an idea as it sounds from reading the article.

Also, the quotation at the bottom of the article from Paul Hoffman is pure nonsense. The fact is that the main barrier to DNSSEC deployment right now is that the government hasn't yet signed the root. They are about to sign the root. The next barrier to DNSSEC deployment is that .COM isn't signed (.ORG is very close to being signed, and a lot of other TLDs are already signed as well). The reason .COM hasn't been signed is largely because they have an excuse. Since the root isn't signed, signing .COM isn't all that useful. Once the root is signed, the excuse for not signing .COM goes away.

Now, once .COM is signed, how much work is it to sign your zone? It takes about an hour to set up. I know because I've already signed all my zones. So this means that any organization that has a fiduciary responsibility to make sure you don't get spoofed (e.g., your bank) can *easily* sign their zone, once .COM is signed.

It is *not* necessary for every zone on the internet to be signed. It is merely necessary that those zones that really matter, and are most likely to be attacked, like bankofamerica.com, get signed.

Next, ISPs have to protect their DNS caches, or else you, if you really care about security, have to install a validating resolver. Installing a validating caching nameserver is not trivial, but it's not that hard. Importantly, it is no harder than installing a hacked caching name server - one that includes one of the several hacks proposed in the DNSEXT working group the other day.

So this is why serious people, including me, are arguing that doing nothing is actually the right thing. That's really an incendiary way of putting it: the fact is that the geeks have come up with a protocol that does the job. We have implemented servers that do that protocol. We have implemented clients that do that protocol. You can get them for free, or you can pay for nicer versions (my company makes one). What is missing is that the people who write the checks haven't written the checks yet.

So when the people who write the checks come to us and say "can't you make it secure," a lot of us answer "we did, why don't you use what we did." It's a little bit PHBish to come back at this point and demand that we do Yet Another DNS security system, particularly one that's a bad hack, when a system already exists and is deployable and not a hack, that will work much better than any of the proposed hacks.

So that's why some of us argued for doing nothing. We are simply telling the PHBs of the world "no, we already did what you need, go deploy that and stop bothering us," not "security isn't important."

Re:So what powers does the IETF have on this?

[mellon]

With DNSSEC, if the person running the root were to sign incorrect data and publish it, this would be easily detected by the consumers of that data. So it would only serve to create an embarrassing international incident - you couldn't use it to actually fool anybody.

Re:So what powers does the IETF have on this?

[Anonymous Coward]

Is anyone on IETF announce? I thought I saw a message come through not two days ago that basically said DNSSEC in the root systems would soon be switched on. They gave the argument that it will be a gradual uptake to DNSSEC which justifies poopooing the traditional overloading root scaremongering excuse.

The same message mentioned the house of cards issue with a "single trust anchor" and me thinking who on earth gets to guard the damn root signing key(s)? with their lives -- least the whole system is compromised by an army of ninjas from your favorite hacker rich nation.

The weird thing is that I could have swarn Microsoft, vixie/ISC et al patched the sequence guessing/poisioning issues weeks/months ago and that most of the Internet has already fixed the problem yet people continue to spout on undaunted as if the world has ended?

The way I see it the Internet is only as good as its weakest link. As long as DNS has the property that sequence number guessing is infeasable without MITM - this is good enough in my opinion. If its not DNS, then it would be BGP, rouge operators/APs..etc with the same results.

The real solution is people really need to be focused on not caring about or trusting the network and thinking in terms of end-end security. The Internet will never be secure unless it ceases being the Internet we all know and love. My 2cents -- use SSH, HTTPS, VPNs..etc and forget about all this DNS gloom and doom nonsense.

sensationalist nonsense - use 0x20 now!

[leto]

Stupid sensationalism.

You can right now use draft-vixie-dnsex-dns0x20 to protect against the kaminsky bug. This option is already available in the unbound nameserver.

Talking about totally talking out of context. Fools!

If IETF does something to mitigate, the unbelievers scream "see we dont need dnssec"

If IETF does not do something, the unbelievers scream "you're blackmailing us into dnssec"

Stop whining and put your foot where your mouth is.

Re:Misreported

[Anonymous Coward]

Here is my humble opinion.

Fix this bug, then set a date where everybody has to move to DNSSEC and IPV6. Let's say 01/01/2010.

Make it mandatory, or else...

Then be done once and for all with this old tech.

Re:Misreported

[pawal]

I was also in this meeting. One of the following comments (from whom exactly, I don't remember) was that all of the DNS namespace will never be signed using DNSSEC, there will for a very long time if not always, be gaps in the namespace that won't be signed at all.

There are also other reasons to run an unsigned zone for shorter times, but I won't go into details about that.

So we should probably strengthen the DNS protocol in other ways than using DNSSEC, but those improvements must not be ugly hacks.

Re:Misreported

[Chris Burkhardt]

Is DJB's DNSCurve a viable solution?

Re:Misreported

[mrsbrisby]

Yes, but not more then DNSSEC, which is a published, widely implemented, and tested system.

I disagree. DNSSEC isn't widely implemented, and the widest test had numerous problems.

DNSCurve is 100% compatible with DNS. There's nothing a firewall could do that would be compatible with DNS that is incompatible with DNSCurve.

DNSSEC is not.

DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.

DNSCurve protects against denial of service attacks. It requires far less compute-power than DNSSEC.

It's hard to make a case for the need to protect the DNS traffic from sniffing, the threat is modification, not sniffing.

Rubbish. Even an amateur cryptographer would tell you that the more you know about the message, the easier it is to break it. Confidentiality protections reduce the amount of knowledge, and thus protect against attacks that are yet unknown.

I would like to see elliptic curve crypto standardized and used in DNSSEC as it will significantly save on the traffic needed, but that is something that can be easily changed later. DNSSEC is very extensible and designed with the future in mind.

I don't think you know what you're talking about.

Re:Minneapolis?

[Spazmania]

Minneapolis has a "Skyway." Basically, many of he buildings downtown are connected via heated walkways between the second floors. These second floors form literally miles and miles of indoor pedestrian mall. The Hilton where the conference is held is connected to it.

So basically you can go everywhere without having to ever go outdoors. And we have a gig-e Internet link for the duration of the conference. Its computer geek heaven.

Re:Stupid, stupid, stupid!

[mellon]

1. No, it doesn't. The zone is signed once, and then queries are served out of cache. The server does not have to sign its response to each query.
2. Some firewalls are broken? What else is new?
3. This isn't true. Every name server out there except for djbdns supports dnssec. It took some real work to add that support, sure, but the work is already done. If you want DNSSEC support, you can have it now.
4. Hm. I had to add a single cron job to automatically resign the zone once an hour. Big whoop.
5. Publishing a name in the DNS requires cooperation from the parents. This is a non-issue.
6. No, it doesn't. It requires that validating clients reject unsigned data from zones that are signed, and provides a secure way for those clients to determine whether or not a zone is signed. This is why DNSSEC protects against the Kaminsky bug. If we took this feature out, DNSSEC would be useless.

Re:Minneapolis?

[mellon]

Eh, the whole downtown is covered in habitrails, so you can walk from building to building in short sleeves, because you don't ever have to go outside. It's kind of like living on a really big space station, only with gravity.

It was kind of cold in my hotel room, though.

Emphasis on *amateur*

[jonaskoelker]

Even an amateur cryptographer would tell you that the more you know about the message, the easier it is to break it.

And a professional cryptographer would tell you to use a signature scheme that is provably secure (under standard cryptographic assumptions) against known plaintext signature forgery, and use a key big enough to satisfy you. Heck, you do all the crypto off-line, so you can pick a big one.

Confidentiality protections reduce the amount of knowledge, and thus protect against attacks that are yet unknown.

Prove the security of your signature scheme in the Universal Composability model and it's secure against all attacks, known and unknown.

I don't think you know what you're talking about.

Oh the iro... No, actually, you _do_ know what you're talking about: amateur cryptography.

DNSCurve protects against denial of service attacks [link]

So to back up your claim, you post a link to someone making the same claim. Now I'm convinced...

It requires far less compute-power than DNSSEC.

Yes, but it requires it on-line. It also requires caching keys for your clients unless you want to double your in- and outbound packet load.

Read the page about DNSCurve. It says "DNSCurve and DNSSEC have complementary security goals. If both were widely deployed then each one would provide some security that the other does not provide."

They're, taken at the word, not meant to replace each other.