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.

Maybe it's for the best...

[Anonymous Coward]

From what I've read, the possible fixes for DNS don't address the cause but just the symptoms and could (according to some: will) cause new, more complicated problems later on. And approaches that might really robustly work could be such that deploying DNSSEC will be simpler. And there's also the angle that we already have a well engineered solution to the problem, let's deploy that instead of engineering a new ugly solution. In the end, if it really becomes a problem it will get fixed either way, so we might as well do it right.

Stupid, stupid, stupid!

[Opportunist]

Now, when, and I mean EVER, has a security hole meant that people switch to a new platform? Or when has a severe security hole EVER caused people to even consider moving?

Windows has its leaks. But people keep using it. Why? Because they don't care, don't know or because "hey, what are the odds that it happens to me?". SMTP and POP have flaws, spam is running rampart because of it, and we switch to securer ways of mailing that can verify the sender... not! IPv4 has security problems and we're not even seriously considering switching to something more secure.

People will NOT switch to something else just because of a security problem. Because the people who could enforce it simply don't care. ISPs? ISPs don't even care about trojans running rampart in their network. Most don't even bother trying to block Sasser from spreading. The governments? Spare me that, currently I'd rather expect them to use the flaw themselves for better surveillance of their subjects.

Fix that damn bug! Nobody will move to a better platform just because of a "mere" security problem.

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

[Znork]

sound like recommending that everyone start playing Duke Nukem Forever.

Yes, with the limitation that only one can have the keyboard at a time.

Considering that both Europe and China are launching their own satellite navigation networks, largely as a distrust issue, the idea that a single signed DNS root will be politically digestible over anything but a very short term shows a certain... detachment... from the actual politics of the world.

I suspect that even if DNSSEC gets deployed to any large extent it'll get fractured again due to missteps by the controlling organizations (You gonna sign that Tibet key or not?).

In the end there are other solutions that might be more palatable. You could specify multiple servers against which to cross-check DNS lookups, you could store keys after first access, (and to solve Kaminsky it's even easier as you could just extend the random id code) etc, etc. The hierarchial trust structure appeals to some, particularly as it fits DNS very well, but it has some problems that may perhaps never be resolved and that can render it incompatible with reality.

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

[timeOday]

The big problem is that most of the TLDs don't support DNSSEC (not sure if the root servers do, but I think they started a little while ago).

Well, they don't support some other as-yet-nonexistent alternate security fix for the Kaminsky Bug, either.

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

[Incongruity]

This sounds like a good idea on the surface -- it'll never happen, of course, because too many companies and individuals have too much invested in the .com, .net, etc. without the country codes... but still, I like the consistency it all brings.

Re:Stupid, stupid, stupid!

[mrsbrisby]

Actually, there are a lot more than two major holdups:

1. DNSSEC is slow. It makes your nameservers vulnerable to denial-of-service attacks
2. DNSSEC is incompatible with many firewalls; publishing DNSSEC will make you invisible to some sites
3. DNSSEC is very complicated. It's very hard for nameservers that aren't based on BIND to implement it. I should point out that the nameservers that aren't based on BIND have actually been practically immune to the recent DNS attacks...
4. DNSSEC requires administrators change their behavior significantly. This means retraining and reimplementation of many processes
5. DNSSEC requires cooperation from all the parents, not just the roots.
6. DNSSEC requires that clients reject unsigned data

The list goes on. There is another way [dnscurve.org], but because the BIND company controls a root server and has voting powers, and "because we've already invested so much in DNSSEC", it's unlikely the deadlock will be broken: DNSSEC will continue to suck so badly that nobody will want to use it, and other systems will be blacklisted because they're not DNSSEC.

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

[Intron]

It is relatively easy to fix the bug locally - at the end of any DNS lookup don't cache any of the information that was used. The bug is due to using cached information received for the lookup of domain A when looking up domain B. The problem is that if everybody did this it would put a tremendous load on the DNS system. All DNS lookups would start at the root servers and work their way down using only authoritative records.