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

DNS

[Anonymous Coward]

TMBG37 GOES TO THE MARKET
        -or-
DNS for fucking idiots.
(NONE LIKE IT HOT!)
 
1. TMBG37 tries to go to www.dildomall.com with his browsar.
        a. His local machine checks if he's been there recently
          and if it remembers the IP address.
        b. Let's assume (big assumption people), that TMBG37
          hasn't been buying any rubbery cocks of late (ha!),
          his computar connects to its local nameserver.
                --> HELO MISTAR NAMESERVAR
                <-- Oh fuck it's you :(
                --> WHERE DO I BUY DILDOES?
                <-- Shit kid I don't even want involved with that.
                --> GIVE ME ADDRESS FOR www.dildomall.com!!!!!
                <-- Fuck you. But fine, its nameserver is
                    ns1.bunghole.org, which is 69.69.69.69.
                --> THANK YOU SIR
        c. His computer goes on to pester ns1.bunghole.org, via
          its IP address, which it got from the local nameserver.
                --> OMG R U ns1.bunghole.org?
                <-- Oh christ, I've heard about you :(
                --> OMG PLZ WHAT IS www.dildomall.com !!!!?
                <-- Leave me alone.
                --> PLXX?????
                <-- It's 37.37.37.37
                --> OMG HHLUAHGLAUHGALUHGUH *SUCKING DICK*
2. TMBG37 goes on to happily penetrate his anus with a dildo
  bought from www.dildomall.com, with the IP address 37.37.37.37.
  There are HTTP/1.1 issues involved here if it is using virtual
  hosting, but that's NEITHER HERE NOR THERE.

Re:DNS

[lukas84]

It looks like you mixed up the resolver and the client.

Re:DNS

[MadnessASAP]

Why is this troll? This is some funny shit and does seem to be largely accurate.

Re:DNS

[kayditty]

and he doesn't seem to understand recursion, either.

Re:DNS

[pleappleappleap]

To know recursion, you must first know recursion.

Re:DNS

[superdave80]

Consider my mind officially blown.

Re:DNS

[Spazmania]

You keep that up, I might just blow my stack.

Re:DNS

[Anonymous Coward]

If you think Fibbonacci is bad, try the Ackermann function! :) Or, more realistically, or traverse Graphs and Trees or utilize Netwon's method and Simpson's rule!

Re:DNS

[andreyvul]

Thank you. I now have something even more mind-blowing to add to my .sig.

Re:DNS

[Anonymous Coward]

I've looked up www.dildomall.com and it's 216.8.179.24, you insensitive clod!

Re:DNS

[Anonymous Coward]

This is better in its original LOLDONGS cartoon form.

Re:DNS

[hesaigo999ca]

Gives a whole new meaning to packet sniffer.

DNS to slashdot has been hacked ....

[cullenfluffyjennings]

and I am reading the wrong site. The aliens can return the real slashdot now. Surely IETF would never choose to "Do Nothing" :-)

Re:DNS to slashdot has been hacked ....

[jd]

They haven't "done nothing" - they specified an Evil Bit that attackers are required (by spec) to set. If attackers are failing to set the Evil Bit, it isn't the IETF's fault. That's an implementation issue.

Re:DNS to slashdot has been hacked ....

[Intron]

At least link to the RFC

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?

[e9th]

It sounds like they'd really like to see the root servers implement DNSSEC, which might result in a trickle-down effect to others DNSes.

But if we can't even stop people from having their authoritative servers also act as recursive caches, I don't hold out much hope.

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

[timeOday]

Unlike Duke Nukem Forever, DNSSEC actually exists, and from what I gather, the main problem is getting people to adopt it. 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). It would amount to wishing away the problem of mass adoption.

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

[cjfs]

IETF participants pointed out that DNS software packages from BIND, Nominum, Microsoft and NLnet Labs have added patches for the Kaminsky bug, and 75% of DNS servers have been upgraded to thwart Kaminsky-style attacks. The IETF also is putting the finishing touches on a best-practices document that outlines ways for DNS server operators to protect against spoofing attacks like those that exploit the Kaminsky bug.

So you're correct. Patches are out and the IETF is just debating their stance.

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

[TheRaven64]

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). This means that, even if you want to use DNSSEC, you can't, because the chain from the root to you is insecure and there is no chain of trust to you, so you gain nothing.

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?

[Tjebbe]

Those patches are no fix, they only make the attack a little bit harder, and were easy to do without changing the current protocol or authoritative server software.

Most of the proposed interim solutions do require a change in the protocol and/or authoritative server software, and those will need to be supported until the end of time (or when DNS goes away, which is probably not before a decade after that), and make debugging of misconfigurations that much harder, especially when several of these additions would be combined.

That is why some people are hesitant to standardize these solutions (or implement DNSSEC, for that matter).

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

[Creepy Crawler]

Who said YOU have to trust anybody?

Instead, we rid ourselves of all domain names that do not state country code (.com, .net, .gov, ...). Then, each country sets up a national Pubkey Archive and authenticates via their country key. Each country sets their own up, so they are in charge, not some arbitrary country "somewhere else".

That idea also easily allows enterprising "hackers" and other types to have their own auth server and provide their own domain setup. All you need do is to aim your domain resolver at the domain master and you can resolve them now. It's just like how ToR provides lookup of .onion

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

[Zero__Kelvin]

From the Wiki article you link to:

It is widely believed that deploying DNSSEC is critically important for securing the Internet as a whole, but deployment has been hampered by the difficulty of:

1. Devising a backward-compatible standard that can scale to the size of the Internet
2. Preventing "zone enumeration" (see below) where desired
3. Deploying DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)
4. Disagreement among key players over who should own the .com (etc) root keys
5. Overcoming the perceived complexity of DNSSEC and DNSSEC deployment

Some of these problems are in the process of being resolved, and deployments in various domains have begun to take place.

I guess we have different definitions of "exists", unless you mean it exists as a list of as yet unsolved problems.

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:So what powers does the IETF have on this?

[superdave80]

Ummm, it does exist. It just hasn't been deployed, due to the issues listed.

Car analogy alert:
I have my car (DNSSEC) sitting in the garage. It exists.

I want to drive (deploy) it, but my wife, teenage kids and I are all arguing over who gets to drive, where we are driving to, and what route we are going to take.

Hell, your own post states it:

...and deployments in various domains have begun to take place.

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?

[mrsbrisby]

Hesitant? Hesitant!?

Look, this isn't a bunch of ninnies holding back progress. DNSSEC is a replacement for DNS. It always has been, and for some god awful reason it's taken its architects over a decade to get nowhere. Deploying DNSSEC gains you nothing and costs you a lot: You have install costs, heavier hardware, changes to your internal infrastructure- those are the obvious ones-then you've also got the fact that the DNSSEC tokens will get your DNS packets stripped by some firewalls which means you disappear from the Internet- and this is my favorite, DNSSEC actually reduces security by making it easier to launch denial of service attacks on you.

Meanwhile, competing systems are rebuffed as "we've already invested all this time into DNSSEC".

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

[Zero__Kelvin]

With all due respect your analogy is quite horrible. Allow me to remap it to reality

"I have my car (DNSSEC) sitting in the garage. It exists."

We have a national highway designed to permit or deny traffic based on road signs, traffic laws, and traffic law protocol and the police as a kind of ICMP.

"I want to drive (deploy) it, but my wife, teenage kids and I are all arguing over who gets to drive, where we are driving to, and what route we are going to take."

The entire country, nay the entire world, would like to switch over to a system where RFID devices and sensors are used to perform the function. How will we make the transition without blocking major interstates and similar routes from the first day of transition through to its completion?

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

[lysergic.acid]

you need to work on your reading comprehension skills.

DNSSEC exists plain and simple. it's already been deployed for a lot of domains and root nameservers. just because there are difficulties hampering its widespread adoption doesn't mean it doesn't exist. that's like saying IPv6 doesn't exist because it's still suffering from a lack of widespread adoption.

none of the factors preventing more widespread deployment are problems that need "solving." in fact, they're more social/political problems than they are technical problems. so the "solution" to these problems is simply to persuade/pressure/coerce DNS servers to adopt DNSSEC, which is what IETF is debating about.

1. backward-compatibility may be difficult to maintain, but this is a transitional problem, and it's not a real technical barrier to adoption at this point. BIND 9.3 (several older versions are compatible as well) officially supports DNSSEC, so does NSD, and Nominum's ANS and CNS. the fact of the matter is, there are tons of domains already using DNSSEC without issue.
2. the zone enumeration issue has already been solved with NSEC3 (RFC 5155) released in March--which you'd already know if you'd read the rest of that Wiki article.
3. this is a logistical problem that every new technology/protocol/standard faces. the main issue here is the last-mover advantage. nobody wants to be the first to adopt a new standard when there's no financial incentive to do so. but somebody has to go first. and at this point there is already a wide variety of software, prototype systems & tools available for implementing DNSSEC with little to no risk involved.
4. this is purely a political issue, and it has more to do with the U.S.'s monopolistic control over the DNS system than DNSSEC. perhaps if ICANN acted more impartially instead of getting in bed with Verisign and other commercial corporations we wouldn't have political BS hindering technological progress. in any case, this is an ICANN problem and could be solved by organizational reforms to make ICANN operate with more transparency and give other nations a voice in domain name management.
5. the perception of DNSSEC being too complex or difficult to adopt is just that--a problem with public perception. IETF is working on resolving this problem through education and training, which are on their deployment road map. there's a lot of good free resources out there to help ease others through this transitions and dispel false perceptions.

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?

[mellon]

Argument by vigorous assertion? If people are interested in delving deeper, reading the namedroppers and dnsop mailing lists for the month around the release of the Kaminsky bug would be instructive.

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

[Anonymous Coward]

DNSSEC sucks beyond belief. I vote we do nothing until something different, better, and actually well thought out comes along.

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

[Anonymous Coward]

Don't forget the part where you need to sign all of your DNS zones every 15-30 days, bloat your DNS zone files considerably, restructure your zone directory/file layout, set up a second cron job on another server to check that your first zone signing cron job is working, the possibility of having your domain go offline for all DNSSEC enabled resolvers if your automatic key signing silently fails, and the fact that you have to trust ISC's "domain lookaside validation" as an alternate trust heirarchy since the root level zones aren't signing any keys.

ISC is trying to ram this down people's throats. Come up with something good and people will gladly migrate to it without all the scare tactics. Just install a djbdns caching server and you'll be fine. Seriously.

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.

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

[Zero__Kelvin]

"you need to work on your reading comprehension skills."

"ROTFLMAO. You might want to hone your writing skills to the point where you know how and where to use C apital letters :-)

You are quite mistaken as well. I was able to comprehend the fact that you are not particularly smart without having to read a single complete sentence!

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

[dkf]

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.

If you've got e-mobsters smacking companies around a lot with DNS cracks because .com, etc. aren't signed, you will see migration to signed domain trees. And masses of bitching. (You'll always get that.) Or possibly people stopping the arguments over root domain signing and getting on with it by appointing someone to do it. But still with the bitching.

The biggest slip-up in DNS was how the .us domain was managed for many years. And it was a policy mistake, not a technical one.

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

[mrsbrisby]

The namedroppers list has, in the last 10 years I've been monitoring it, been a source of misinformation and frequently mismanaged.

Kaminsky's bug is a rehash of an old bug that non-BIND nameservers were already strong against.

If your sole source of information about DNS comes from the likes of Randy Bush, you sir are an embarrassment to network administrators everywhere.

1. According to the IETF, DNSSEC was started in 1993. That's far longer than a decade.

2. A controlled, toplevel deployment of DNSSEC to .SE knocked out a number of .SE sites. Look at this for more details.

3. If you honestly think there aren't install costs with replacing DNS with something else, you're a fucking idiot and not worth my time..

Argument by vigorous assertion? Please. This is common knowledge. The BIND group says this isn't important, and DNSSEC is almost there.

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.

Re:sounds familiar

[tpwch]

this is somewhere along the lines of not having a secure os and recommending everyone to use an antivirus, a firewall, antimalware and antiphishing.

as far as i understand IETF = Internet Explorer does anyone know what TF stands for?

It stands for Internet Engineering Task Force, it has nothing to do with Internet Explorer.

You can read about them on wikipedia.

How many legs does the Kaminsky bug have?

[pandrijeczko]

If it's eight, then it's probably that perishing missing space station spider!

In which case, you go get the vacuum cleaner and I'll stand here shaking in the corner emitting arachnophobic screams...

Re:How many legs does the Kaminsky bug have?

[cstdenis]

It's a space station. You don't need a vacuum cleaner. Just open a window.

Re:How many legs does the Kaminsky bug have?

[pandrijeczko]

I concede defeat, sir.

I cannot think of a witty retort to one of the best "smartarse" replies I have ever had.

Re:How many legs does the Kaminsky bug have?

[scrib]

If it's eight, then it's probably that missing space station spider!
I'll stand here shaking in the corner emitting arachnophobic screams...

I'm sorry, I can't hear you scream...

Re:How many legs does the Kaminsky bug have?

[pandrijeczko]

That was funny but cstdennis deserves drowning in positive "+1 Smartarse" moderations...

Re:How many legs does the Kaminsky bug have?

[jacquesm]

It hurts. And you owe me a new keyboard. Know that your life was not in vain, even if you never surpass this.

Re:How many legs does the Kaminsky bug have?

[lgw]

It's a space station. You don't need a vacuum cleaner. Just open a window.

No way! That would make a vacuum dirtier!

Re:How many legs does the Kaminsky bug have?

[pleappleappleap]

Groan!

This is...

[Jonah Bomber]

...exactly why we shouldn't eradicate smallpox.

AFAIK...

[mebrahim]

so has been IP, SMTP, etc.

Old news?

[Bearhouse]

As often, Ars Technica has had this for a while.

http://arstechnica.com/news.ars/post/20080726-new-dns-exploit-now-in-the-wild-and-having-a-blast.html

I quote:

"This would be less of an issue if the widely released patch from two weeks ago had been fully deployed"

And:

Moving to the more DNSSEC system would have solved this problem, and that idea was apparently floated, but it was dismissed on account of the tremendous overhead required by this protocol. The patch that currently exists is not a foolproof solution, but it minimizes the chances that the attack will succeed. "The exploit is now tens of thousands of times harder, but still possible," Kaminsky stated during his Black Hat webcast. "one in several hundred million to one in a couple billion."

Yawn.

Re:Old news?

[Red Flayer]

"The exploit is now tens of thousands of times harder, but still possible," Kaminsky stated during his Black Hat webcast. "one in several hundred million to one in a couple billion."

You know, for all of Kaminsky's brilliance, he's got math problems.

Going from "one in several hundred million to one in a couple billion" is not "tens of thousands of times harder". I guess it would make his quote a little less exciting.

"The exploit is now tens of times harder" just doesn't have any flair to it.

Re:Old news?

[pleappleappleap]

That's not what he meant. He meant that the chance is *now* between one in several hundred million and one in a couple billion.

Re:Old news?

[Anonymous Coward]

In your haste to be the cool we've all been waiting for, you forgot the point of the post and got caught up in the back story.

I quote:

"Meeting in Minneapolis this week.."

So it's current news. And no shit, everyone is well aware the issued with a solution.

Perhaps you need a nap, you sound tired.

Re:sounds familiar

[Anonymous Coward]

(I'm a different AC.)

Heavens, you read and post on Slashdot and know neither what the IETF is nor how to google for the term?

Turn in your geek certificate immediately!

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:Stupid, stupid, stupid!

[Anonymous Coward]

This is a little different in the case of Windows. Average Joe doesn't know or care about security holes in Windows. However, the people running and financing the servers being affected by this bug, are not average Joes. Trust me, these people care.

Re:Stupid, stupid, stupid!

[spinkham]

DNSSEC *IS* fixing the bug.
It's a protocol problem, and needs a protocol level fix.
DNSSEC is an extension of the DNS protocol, and if any party in the transaction doesn't support it or ask for it, DNS still acts just like DNS. If the resolver asks for DNSSEC information, and the DNS server supports it, then you get the normal DNS information + the DNSSEC information.

This is NOT switching to a new platform, it's adding a signature to the existing platform for verification. It can work precicely because it is backwards compatible, and doesn't require everyone switch at once.

It DOES pretty much require a signed root, which is the primary hold up. However, at the moment there are countries where the top level domains are signed, and have a fairly good deployment of DNSSEC.

Re:Stupid, stupid, stupid!

[Opportunist]

No, DNSSEC would fix the bug. IF, and only IF, everyone used it. Actually the fact that DNSSEC accepts insecure DNS requests makes this approach flawed.

It's not a technical problem. It's an economic one.

Switching to DNSSEC means additional costs for ISPs. Additional time for server admins, additional hassle to get the verifications, signatures and certs. In one word, expense. Expense without revenue.

Now, old school, insecure DNS works. The customer doesn't see a difference (most of all, he doesn't understand why DNSSEC would be a good idea, if he heard about it at all). Security has never been a selling point for ISPs. Price is. The customer won't request secure DNS and for almost every potential customer of an ISP the question whether a provider uses secure or insecure DNS is not going to influence his decision which one to take. If he has a choice at all, that is.

I do agree that switching to DNSSEC would be a damn good idea. But you, me, some others on /. and a handful more understand the implications. That's not even a percent of a potential customer base for an ISP. So it doesn't matter.

As long as there is no meaningful pressure on ISPs to adopt DNSSEC, they won't do it. And by meaningful, I mean someone or something requiring you to come from a provider address using DNSSEC to do business with you (banks come to mind). But since they again don't want to lose customers (due to requiring it while some other bank/business doesn't), they won't press for it either.

If you want to force people to use DNSSEC, you have an ally in me. But you will not convince a sizable portion of the users, or even ISPs, just by keeping the alternative insecure. They won't care.

Re:Stupid, stupid, stupid!

[spinkham]

Comcast is currently running publicly available DNSSEC enabled testbed: http://www.dnssec.comcast.net/

All the service providers are fed up with having to rush to patch all their DNS servers for a major break about once a year, and the time is right to convince them to switch after the largely publicized Kaminsky bug.

There are 2 major hold ups on DNSSEC adoption:
The root is not signed, and Microsoft doesn't support it.

Pretty much every other DNS server besides MS supports DNSSEC, and most now support the privacy preserving NSEC3 variant also.

Personally, I don't care if ISPs support it right away as I run my own recursive nameserver and avoid my ISPs like the plague, but I know that puts me in .00001% of the Internet.

Re:Stupid, stupid, stupid!

[pleappleappleap]

The last thing I expected is that spam would "run rampart".

Re:Stupid, stupid, stupid!

[Opportunist]

Sure they do. At least a sizable portion of them does. But they don't get the money from the economy guys to do it. Because they do not understand it. All they understand is that the customer accepts a shoddy solution and doesn't care if you offer a better one, and the better one costs money (time, certs,...) to implement.

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, 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:Stupid, stupid, stupid!

[Idiomatick]

chinese farmers = spam and they are running ramps for loots....

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:Stupid, stupid, stupid!

[Opportunist]

Pretty much every other DNS server besides MS supports DNSSEC

Can you see someone with deeeeeeeep pockets doing what they can to keep DNSSEC from becoming popular?

Re:Stupid, stupid, stupid!

[Anonymous Coward]

Well, Microsoft 'sort of' support it.

http://technet.microsoft.com/en-us/library/cc728328.aspx

Basically a (current generation) Microsoft DNS server will correctly serve a signed zone. But it won't calculate the signing itself, and it won't validate the signatures on data it finds.

However, at least one source says that Windows 7 will include DNSSEC support. (And reading the linked blog post, Windows 2008 R2 is going to have DNSSEC support, including signing even on Active Directory integrated zones.)

Re:Stupid, stupid, stupid!

[ultranova]

DNSSEC is an extension of the DNS protocol, and if any party in the transaction doesn't support it or ask for it, DNS still acts just like DNS.

So Joe hacker can simply intercept DNSSEC packets and send forged DNS packets in their stead ? He doesn't need to forge the signature, he can simply strip it off ?

Re:Stupid, stupid, stupid!

[dkf]

Pretty much every other DNS server besides MS supports DNSSEC

Can you see someone with deeeeeeeep pockets doing what they can to keep DNSSEC from becoming popular?

But why would they? Funnily enough, leaving their customers wide open in this area isn't actually in MS's best interest, and they've for sure got the developers to be able to fix this. I'm a cynic, but I expect that we'll see updates in this area.

Re:Stupid, stupid, stupid!

[Opportunist]

Which makes the whole mess even worse. First, DNSSEC won't become the standard and second, MS will, maybe for the first time, be able to claim correctly that their software is more secure than any alternative. Any alternative in widespread use, that is.

Re:Stupid, stupid, stupid!

[mrsbrisby]

1. Yes it does. Dodging the question by pointing out what content servers can do it is irrelevant. Caches will have to check the packets each and every time. Furthermore, the content server does have to re-sign periodically.

2. There's no reason the protocol had to be changed. DNSCurve proved that. The fact is that the DNSSEC people have had since 1993 to figure this out, and this is very strong evidence that they're bonkers-wrong.

3. It's very true. Maradns doesn't support dnssec. LDAPDNS doesn't support DNSSEC. Every code base not based on BIND lacks DNSSEC support. It doesn't help that DNSSEC is so new, and it doesn't help that DNSSEC is so complicated.

4. It's clearly very easy for very small sites to switch to DNSSEC. Especially if you're the only guy operating it. The real Internet isn't like that.

5. No, it's a serious issue. The parents need to support DNSSEC. The parents do not need to support DNSCurve.

6. A MITM attack could prevent a client from ever knowing that a parent was signed. Unless clients reject unsigned data, DNSSEC is useless.

Re:Stupid, stupid, stupid!

[spinkham]

DNSSEC support is in the current pre-beta releases of Windows 7, and I'm sure it will get added to their next server platform release also.

The requirement to sign all .gov domains by next year means MS has to support it or lose government support. Though personally I hope no government agencies are using MS DNS servers, that's a different rant...

Re:Stupid, stupid, stupid!

[spinkham]

That is a policy decision not covered by the DNSSEC standards. He would have to do that for all traffic to the root and TLD servers for that attack to be affective, and you would have to be set up in a way that would allow unsigned root traffic as valid.
Which is to say, no, that attack won't work for any sane deployment.

Re:Stupid, stupid, stupid!

[spinkham]

1. DNSSEC does in fact make DOS attacks worse in the very same ways DNSCurve makes DOS worse: Resource usage and bandwith. However, DNSCurve makes authoratative server computer useage worse, while DNSSEC does not. DNSSEC with RSA makes bandwith useage worse then DNSCurve with ECC, which is why DNSSEC will soon support ECC.

2. DNSCurve misses a lot of the extensibility and forward compatibility including ability to roll over keys, have offline signing, and switch to new crypto alogorithms. All those things are important to a long time secure DNS.

3.This is not true. Namesurfer Suite has both a BIND based and proprietary DNSSEC aware server, NLNET labs has NSD and Unbound, Xelerance and Nominum now supports dnssec, and many more. There's a nice chart of capabilities in this report on page 5 and 6, and more have been added since then.

4.This is a tool problem, and many tools are avalible and being made to make this simple.

5. This is false. True, the parents do not need to modified to accept DNSSEC KEY records like they do for DNSSEC, but the parents themselves must use DNSCurve, or the chain of trust is broken and the protection of that one link is meaningless. In both schemes, the parent must support the security standard to gain anything.

6.This is not true. The end-user needs the root key ahead of time, and then there is NOTHING a MITM can do to convince the client that the information shouldn't be signed. This sort of attack is why the chain of trust from the root is important, and similar to the reason why the NSEC or NSEC3 records must exist. DNSSEC provides much stronger resilience in the case of MITM then DNSCurve.

Re:Stupid, stupid, stupid!

[mrsbrisby]

1. Wrong. Go read the DNSCurve implementation guide to see why.

2. Extensibility is a red herring. Adding a new keying system or cryptodevice still requires rolling out software and hardware changes on a scale similar to rolling out DNSSEC in the first place.

3. Yes it's true. All of those servers you named are based on the BIND source tree.

4. You're a tool problem. Verizon sent out tens of thousands of routers with an embedded DNS server on them. An embedded DNS server that drops DNSSEC information. All of those devices need to be replaced in order to support DNSSEC. None of them need to be replaced in order to support DNSCurve.

5. You say I'm wrong, and then say I'm right. The parents don't need to support DNSCurve because the cryptographic information is saved in the NS record. That means that the attack must be focused on the root servers to succeed; meanwhile ANY MITM attack on ANY content server can break DNSSEC by simply blocking the signing information.

6. "The end-user needs the root key ahead of time" means what I'm saying is true. DNSSEC gains no security unless clients can drop/ignore unsigned packets.

Re:Stupid, stupid, stupid!

[spinkham]

1. I have, it has the same attacks with the same problems. He redefines DOS attacks as simple forgery resilience, which DNSSEC also supports. DOS problems with DNS commonly seen are resource or network consumption issues, on the client, server, or as an amplifier of an attack against a 3rd party. DNSSEC and DNSCurve both do no affect any of these issues besides making them worse. But maybe I'm wrong; the specs suck and there's no implementation to play with. Give me an example where DNSCurve provides protection DNSSEC can't.

2. DNSSEC is extensible, and the hard work of protocol design is done up front. New encryption methods can be added and migrated in backwards compatible in stages, while to upgrade DNSCurve you'd need to design a whole new protocol. Yes, this does make converting to DNSSEC more difficult up front, but DNSSEC is a much better long term solution.

3. No, they are not. NSD is from scratch and the code is available in SVN to verify that. I'm not privy to all the details of the others but some of them do claim to be from scratch. Overall, it doesn't matter. Most (11) vendors support DNSSEC, can you point to one actual implementation of DNSCurve? How about 11 inter-operable implementations?

4. Yes, non-compliant routers are a problem, I admit. Not a large one, as I posit that before end users care about DNSSEC or have software that is requesting DNSSEC information, they will be replaced or upgraded. Windows 7 "pre-betas" which have been released have DNSSEC support, and will be the first end user systems to be compliant.

5-6. DNSCurve needs support all along the chain of trust to the root to be secure. DNSSEC needs support all along the chain of trust to the to root to be secure. Notice the similarity? There are a myriad of attacks against DNS, some where external parties force resolving of domains through various means (think image tags in HTTP). DNSSEC and DNSCurve have the exact same attack profile against all of these attacks.

The interaction between the parent and child is easier with DNSCurve, but because of this there is no way to roll over keys in a manner that doesn't break the security of the system. Otherwise they act the same way.

Main benefits of DNSCurve:
Crappy routers allow it to pass.
Some privacy protection given by encrypting transfers, though doesn't protect against traffic analysis.
Supports smaller ECC today.
Less complicated method of authenticating non-existence of domains.
Overall, less complicated.

Main benefits of DNSSEC:
Tested, secure, with design docs and very good specifications.
Widely implemented in software, though not yet widely deployed.
Allows for very strong key protection for high profile sites, or less security and more convience for low profile sites.
Uses time tested RSA, not a 2 year old ECC variant. Can later switch to ECC if desired.
Allows for rolling over keys in ways that do not break the trust relationship.
Allows for easily adding multiple encryption algorithms.
Overall, more flexible.

In terms of likelihood of deployment, DNSSEC is far ahead:
Mandated by US government and military for deployment in their networks.
Deployed by multiple ccTLDs.
Being tested at the root and reverse zones.
Multiple ISPs have public DNSSEC testbeds.

Re:Stupid, stupid, stupid!

[mrsbrisby]

1. Simple forgery resiliance isn't minor. It is just as difficult to detect forgery as it is a valid key, with DNSSEC, so the cost is magnified by the number of requests. Being able to detect bad packets easier than verifying good packets minimizes the amount of work clients perform.

2. That's retarded. "The hard work of making a protocol" is minimal to the hard work for deploying it.

3. I stand corrected about NSD, but reject the premise that "we've already implemented this far" is a good reason to switch protocols.

4. I think you're wrong. Nobody cares about DNSSEC, they care about not getting to the right website.

5. Wrong. DNSCurve offers some security as soon as some hosts deploy it because as soon as some hosts deploy it, unsigned packets can be rejected from those sites. With DNSSEC, a client may not know if their firewall filters DNSSEC and so would require special configuration.

Tested, secure, with design docs and very good specifications.

Rejected.

Widely implemented in software, though not yet widely deployed.

It took 10 years to reach the point dnscurve reached in 4 months. This is meaningless.

Allows for very strong key protection for high profile sites, or less security and more convience for low profile sites.

By maligning the value of the signing key.

Uses time tested RSA, not a 2 year old ECC variant. Can later switch to ECC if desired.

No it can't. Sites will still need to repeat the deployment operation in order to switch to ECC.

Allows for rolling over keys in ways that do not break the trust relationship.

There is no new trust relationship; The parents simply sign the signing key. Exactly what trust can be inferred from that is independent of DNS.

Allows for easily adding multiple encryption algorithms.

Bull shit.

Overall, more flexible.complicated.

Fixed that for you.

In terms of likelihood of deployment, DNSSEC is far ahead:

It is a sad thing that you are probably right about this. That doesn't mean it's a good thing by any stretch of the imagination.

I think it's downright shameful that the ICANN and the IETF can be bought so easily, that we may soon have to all run software with a known history of security bugs, just as soon as we might all have to compete with companies that can afford to buy their own top-level domain.

In terms of likelihood of actually solving problems, DNSCurve is ahead, and as you point out; there's few implementations (only two to my knowledge), and almost zero deployment.

However, DNSCurve is only a few months old, and already it's almost to the point that DNSSEC is.

Saying "hurry and protect against these security problems by switching to DNSSEC- trust us, we've been working on this for fifteen years" just sounds stupid to me. I think you're probably stupid if you think that sounds like a good idea.

It may be that you think DNSCurve is about as good as DNSSEC, just less mature and less available, but I look at it differently: We're in 2008, and the "deployment problem" of critical infrastructure has yet to be solved. We have sites without MX records, that break mail that isn't 8-bit clean, we have sites that still don't route filter (and for no good reason), and we've still got sites running BIND4.

You simply cannot force people to upgrade, and while I'm sure the BIND group would get it right eventually (I'm told current versions of BIND9 sucks far less than its predicessors) you simply cannot get away with that shit.

Re:Stupid, stupid, stupid!

[spinkham]

Allows for rolling over keys in ways that do not break the trust relationship.

There is no new trust relationship; The parents simply sign the signing key. Exactly what trust can be inferred from that is independent of DNS.

There is a time in the roll-over where you have published a new key, but the old key is still cached. How does DNSCurve deal with this?

About new encryption options: Much like HTTP, DNSSEC can be extended by wherever both endpoints support. OS a new client would get fancy ECC encryption, and older DNSSEC capable versions would get RSA. Over time as people upgrade, RSA gets turned off. That's how compatibility works in the real world.

DNSCurve has some good design decisions, but there are many corner cases that DNSSEC solves that DNSCurve does not address. Still, given time it could be usable, but it's not that much better. DNSSEC deployment can be as easy if you like, offers the same level of protection against MITM attacks, and in general is good enough. You obviously don't think so, but the DNSCurve site pits the best possible deployment options for DNSCurve against the worst possible deployment senario for DNSSEC. DNSSEC can be plug-in simple also. The only real wins for DNSCurve are smaller packets today, and router compatibility. Its downsides are poor key management management and future upgrade path, and even if the tradeoff was worth it (which I don't believe it is), it's not worth throwing away the momentum DNSSEC currently has.

We all wish DNSSEC could be simpler, and if DNSCurve was really much easier to deploy for the same security, I'd be all over it. However, I don't believe it is. Good deployment tools exist for DNSSEC and many more will be created, but DNSCurve's security downsides in key management can't be automated away.

Re:Stupid, stupid, stupid!

[mrsbrisby]

There is a time in the roll-over where you have published a new key, but the old key is still cached. How does DNSCurve deal with this?

The same way you deal with any change of your NS records.

About new encryption options: Much like HTTP, DNSSEC can be extended by wherever both endpoints support. ... That's how compatibility works in the real world.

Rubbish. Compatibility has never worked that way. My site sees over 30 million messages every month; less than 50% of the senders are RFC2821/RFC2822 compliant. Once a standard becomes entrenched, you must operate on the assumption that it always will be.

Eventually, it becomes irrelevant (like Windows), but it never ever gets replaced.

That's how compatibility works in the Real world.

DNSSEC deployment can be as easy if you like, ... DNSSEC can be plug-in simple also.

DNSSEC is replace your infrastructure simple. It requires replacing hardware and software to deploy. DNSCurve requires supplementing software. A forwarder can run alongside your existing DNS content server requiring no special implementation costs.

DNSSEC isn't designed to fix problems, it's designed to replace DNS.

DNSSEC offers the same level of protection against MITM attacks,

No it doesn't.

The only real wins for DNSCurve are smaller packets today, and router compatibility.

Those are extremely important. DNSSEC doesn't have an Internet-wide migration plan; just a myriad of ideas and best practices. Everyone is assumed to figure it out for themselves.

This has obviously worked very well for IPv6...

Its downsides are poor key management management and future upgrade path,

It has exactly the same upgrade path that DNS has because it's 100% compatible with DNS.

I'll get to the key management in a moment.

and even if the tradeoff was worth it (which I don't believe it is), it's not worth throwing away the momentum DNSSEC currently has.

Says you, one guy, who doesn't operate a very large site, or have very much to change.

You're in fact, a very small and singular member of the Internet. Replacing DNS is an Internet-wide change, and it requires an attention greater than you're willing to give.

That's why your opinion is rejected outright.

We all wish DNSSEC could be simpler, and if DNSCurve was really much easier to deploy for the same security, I'd be all over it. However, I don't believe it is.

Your beliefs don't enter into it. It is simpler to implement, and will be simpler to deploy.

Good deployment tools exist for DNSSEC

No they don't. As I said, DNSSEC deployment requires replacing Hardware and Software. You think this is okay because in your mind the Hardware and the Software is broken. DNSCurve does not.

and many more will be created,

This however, is likely, and I agree. I remember old "MX calculators", and "CIDR calculators": Simple things need a lot of tools, complicated things; doubly so.

but DNSCurve's security downsides in key management can't be automated away.

I don't think they're serious. Keys in X509 and DNSSEC represent organizational processes, but this is a layer of overhead that sites apparently don't need: the reality of how SSL and S/MIME ended up getting deployed demonstrates this thoroughly.

The current existing infrastructure of a single delegation controlled and mandated by the parent is something the DNSSEC key system pretends is shared by the delegate.

It isn't true of course: the parent can unilaterally des

Comment removed

[account_deleted]

Comment removed based on user account deletion

Translation....

[Plekto]

"Do nothing"

After applying CIS and corporate-speak filters:

"Aw man, do I have to get up and actually program some code?"

Re:sounds familiar

[jacquesm]

*whoosh*...

You really should have your humor circuits checked you know ?

YHBT

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:sensationalist nonsense - use 0x20 now!

[nog_lorp]

I think Slashdot is more in the believers community. The discussion is more along the lines of "How can we blackmail them into using DNSSEC? Will the Kaminsky bug be effective for that purpose?"

Re:sensationalist nonsense - use 0x20 now!

[kelnos]

I'd be perfectly ok with the IETF "blackmailing" everyone into implementing DNSSEC.

Re:sensationalist nonsense - use 0x20 now!

[Spazmania]

Why is this a troll? 0x20 is in fact one of the proposals for mitigating the Kaminsky weakness.

The idea is: you take each of the letters in the query and randomize the capitalization. The response from the server should have the same randomization. If it doesn't, someone may be trying to hack you so you fall back on a slower, heavier-weight TCP-based DNS query instead. In effect, each letter adds one bit to the 16-bit query ID for the purpose of calculating cryptographic entropy. Combined with source port randomization (which adds another 16 bits of entropy) you force the attacker to spend an impractical amount of resources to briefly forge just one entry.

Re:sensationalist nonsense - use 0x20 now!

[pv2b]

I just read the draft. That has got to be one of the more awesome hacky ideas I've read about this year.

Thanks for sharing!

Re:sounds familiar

[Anonymous Coward]

Kettle, thou art black! Because if that was a joke, it was a complete failure.

Re:sounds familiar

[jacquesm]

oh come on. Internet Explorer Task Force, and then a whole bunch of guys falling over each other to spell out what IETF stands for (As if there is anybody here that doesn't know that. What ? oh, ok... well, never mind then ;) )

DNSSuCk?

[Nicolas MONNET]

1. It's very complicated.
2. It's error prone
3. It's not even going to protect you against many attacks
4. It's coming from the people who wrote bind 4.x, the steaming pile of dung that preceded bind 8.x, the rotting carcass that preceded bind 9.x, the most bloated decomposing corpse of a beached whale of the internet
5. Even sendmail looks better than bind nowadays
6. Last I heard you have to give some more money to Verisign. Sigh.
7. It took them, what, 12 tries to get it "right"? I mean last time they said it was going to be the right one. How do we know this time it's good?

Re:DNSSuCk?

[hardaker]

You'd have to back up many of those claims as at least half of them don't make sense or are inaccurate. Troll anyone?

Re:DNSSuCk?

[mrsbrisby]

1. Have you looked at BIND's implementation of DNSSEC? It's thousands of lines of code alone.
2. See #1.
3. RFC4033: DNSSEC (deliberately) doesn't provide confidentiality; RFC 4033: DNSSEC does not protect against denial of service attacks.
4. The bind people claim that BIND9 was written by "a whole new set of people" but at least thirteen of the developers have been identified to work on both.
5. I'm leaving this one alone.
6. CA certificates were planned for an earlier incarnation of DNSSEC
7. I don't think this requires clarification, but this pdf indicates that the IETF started DNSSEC in 1993.

Do you actually check? Or do you just call people trolls who you don't agree with?

Misreported

[Spazmania]

I was in the meeting. As I recall, one gentleman, I'll repeat that, one gentleman from the audience of a few hundred got up and expressed the opinion that we should do nothing so as to spur DNSSEC deployment.

There was rather more consensus for the view that we should avoid making quick hacks that might obstruct DNSSEC deployment since DNSSEC is currently the only approach on the table that we're reasonably sure ends the problem.

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

[kelnos]

I'd avoid using "DJB" and "viable solution" in the same sentence.

But that's just personal bias.

Re:Misreported

[spinkham]

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

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.

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

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.

Re:Misreported

[LingNoi]

or else what?

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

[Idiomatick]

they cant use the internet. make it not backwards compatible....

Re:Misreported

[Lost Race]

What internet? All the hosts that still support legacy DNS will still be able to talk to each other, and anybody can provide a legacy DNS root (there are already many alternatives to the "official" DNS root). As for IP version, any interchanges that provide IPv4 routing will allow communication between IPv4-only hosts, so there will still be large fragments of the current Internet reachable through IPv4 -- perhaps nearly all of it via extended and circuitous routes. Do you think anybody can exert enough influence to force every interchange to stop IPv4 routing and block legacy DNS packets?

Re:Misreported

[j h woodyatt]

On the other hand, the emerging consensus in the BEHAVE and SOFTWIRE groups appears to be that port randomization isn't beneficial enough in mitigating the general class of port spoofing attacks to warrant rejecting on that grounds alone the various schemes in play for allowing service providers to aggregate multiple subscribers behind the same public IPv4 address while maintaining the network address translation at the subscriber site by slicing up the public port range available to each site.

Don't worry. I'm sure the robots will save us all in the end.

Re:Misreported

[pawal]

The notion that DNSSEC has had a lot of problem (and you take "the widest test" as data for it!) it not true. .SE has had _one_ major problem with DNSSEC and that was due to a bug in BIND which caused some equipment to fail. (The bug was that BIND set the AD bit by mistake, it was promptly fixed.)

Fact is that we have had no problems since, and we now expect a fast rollout. The major problem now is that there is still a lack of tools, not only for TLDs, but also hosting companies and other large nameservice providers.

I have not seen any large deployment of DNSCurve, and I know for a fact that NSD, BIND, Unbound and other major DNS software does not implement DNSCurve...

Re:Misreported

[spinkham]

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.

DNSSEC is currently deployed live in multiple countries, .gov and .arpa are now signed (but only for testing purposes at the moment). Yes, the number of DNSSEC hosts is only in the low 5 digits, but that's still way more then DNSCurve. 11 vendors have DNSSEC compatible DNS servers, which I believe is 11 more then DNSCurve. DNSCurve would have to be significantly better in order to garner support at this stage, and I'm not seeing it.

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.

This is a valid point. Only about 1/4 of recently tested home routers allowed DNSSEC traffic. It's also a problem that is trivial to solve in the long term. Once DNSSEC is deployed, routers will follow. Realistically however, all home routers will be DNSSEC capable before Windows can deal with the DNSSEC data. DNSSEC can still make policy decisions at the ISPs recursive resolver before that time however.

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.

Strange that the link you send doesn't mention DOS attacks at all.
DNSSEC requires 0 more compute power, but does increase network traffic. DNSSEC can be extended to use ECC instead of RSA to reduce the network overhead, with NO computational overhead.

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.

Oh? Read RFC 4034, then get back to me. Elliptic curve crypto already has a specified algorithm type, listed in appendix A.1. Unfortunately, the exact format hasnt been standardized yet. There are 245 more unassigned crypto specifications available for future use, I'd call that extensible.

DNSCurve does have some good ideas since it was designed to be easy to deploy, while DNSSEC deployment frankly sucks. DNSSEC is designed by committee,and it shows. On the other hand, it has many future-proof features like the ability to upgrade the crypto used in case RSA, DSA, ECC, or any other scheme falls like a house of cards, or simply need to be made longer in order to survive attacks.

If DNSCurve was proposed 5 years ago, it would have had a good chance of becoming the standard. Now, frankly, it's too late. Most of the major DNS servers support DNSSEC, .gov is currently signed and all US government sites must use DNSSEC by next year, the root servers and reverse .arpa domains have DNSSEC testbeds, Comcast has deployed their dnssec test servers. The political problems of who holds the root keys will be solved soon and DNSSEC will be live. Whether it takes off or not is a question for the market to decide.

Re:Misreported

[idiotnot]

One of the ideas I had was fixing the randomization size (currently only 16-bit, iirc) only for IPv6 (64-bit, maybe?). Yes, it'd cause some headaches for those of us already using v6, but it would help eliminate the problem.

Of course DNSSEC is the real solution, but it's a ways off, probably after even IPv6 adoption. I know that in some places where I've worked, there's heavy reliance on MS DNS servers. Also, change is very slow to come. Yes, there are still a smattering of NT4 boxes around....and Win95OSR2 on some of the desktops.

Re:Misreported

[mrsbrisby]

That's the great part about DNSCurve. It's so simple BIND could implement it in an afternoon.

DNSSEC isn't supported by DJBDNS, MaraDNS, LDAPDNS, or any other DNS server not based on BIND's codebase. In order to gain DNSSEC support, everyone effectively would have to switch to bind.

I cannot see why anyone would think that is a good thing.

By the way, .SE's major problem was serious. It was really serious. The fact that it hadn't been noticed this entire time- with numerous people saying DNSSEC is almost ready, is frankly very disturbing.

Re:Misreported

[mrsbrisby]

DNSSEC is currently deployed live in multiple countries

No it's not.

DNS security initiatives are about protecting clients. There are zero clients protected by DNSSEC, ergo, DNSSEC has zero deployment.

The big attempt at protecting clients looking up .SE users failed miserably- partly due to a bind bug, and partly because clients didn't bother checking at all.

Strange that the link you send doesn't mention DOS attacks at all.

I'll highlight it for you:

Availability

1. RFC 4033: "DNSSEC does not protect against denial of service attacks."
2. DNSCurve adds some protection against denial-of-service attacks.

If DNSCurve was proposed 5 years ago, it would have had a good chance of becoming the standard. Now, frankly, it's too late.

I disagree. It's 2008 and there are still sites without MX records. It's also impossible for a multihomed site in the US to deploy IPv6. It'll probably be another 10 years before DNSSEC sees any deployment whatsoever.

On the other hand, it has many future-proof features like the ability to upgrade the crypto used in case RSA, DSA, ECC, or any other scheme falls like a house of cards, or simply need to be made longer in order to survive attacks.

You don't get it. Leaving some bits open to replace the protocol either isn't the same as future-proofing. You'll just make everyone switch DNS servers again- only this time it'll be to BIND 12.

The deployment problem is everything. That's what MX records and IPv6 and IPSEC have proven. Deployment is impossible; your best bet is incremental improvement, and because the BIND group is digging their heels in about that, everyone suffers.

Remember: The recent DNS bugs were predicted over a decade ago. The BIND group said don't worry, we'll have DNSSEC done soon, but other DNS server vendors (all those not based on BIND) adopted the very simple method of being immune to them.

DNSSEC has been about "trust us, we've been doing this for a long time", and frankly that's not enough.

Re:Misreported

[spinkham]

Ah, DNSSurve seems to claim to protect against DOS attacks by a MITM. Honestly the MITM problem is the LEAST of the DOS attack problem, and there's no reason DNSSEC servers couldn't be trivially modified to behave the same way. In fact DNSSEC is silent on how to handle badly signed or corrupted packets, and that sort of DOS breaking capability is within the standards. The classes of DOS attack mentioned in RFC 4033 (resource and bandwidth consumption ) as well as the ability to use DNS as a DOS amplifier work the EXACT same way against DNSCurve. Perhaps I am missing something, but the DNSCurve docs are poor and incomplete and don't mention DOS anywhere but in that blurb.

Here's why the DNSCurve chart is a bunch of crap:
1) He attacks NSEC3 as already reversable. This is blatantly false, SHA-1 currently used is MUCH harder to reverse then simply querying the server. If SHA-1 fails, new signing algorithms can be used instead. The way that NSEC3 CAN be attacked is through a dictionary attack, and if you have dictionary words as DNS names, they can be recovered just as easily by brute-forcing the server. The protection is the same, as you only get a limited amount of NSEC3 records per query also, so server side protections against brute forcing DNS records would be the same sorts of protections against querying for all NSEC3 records.

2) He attacks DNSSECs use of 1024 bit RSA. DNSSEC does have RSA as the only manditory public key cypher, but it does NOT specify bitlength. 2048 bit keys as key signing keys are the likely length at first, and 1024 bit is just a strawman that doesn't exist in the specs. As already discussed, DNSSEC can be, and is in the process of being extended to use ECC or any other public key crypto.

Here's the case for why DNSCurve isn't good enough: DNSCurve REQUIRES that the signing key be online. DNSSEC can operate with the signing key online, and gets easy deployment on the server side. The only way it would be harder then DNSCurve is that you have to send your parent server a DNSKEY in addition to a glue record. It's still a copy paste on your side, but it does require your parent is DNSSEC aware.
Alternatively you can operate in off-line mode, where you have to do the signing offline on a non-connected machine, and copy the records back to the server. DNSSEC deployment dificulty is a tool issue, and there are a number of good deployment tools written that take the difficulty out of it. DNSCurve is simple by design, but not secure and not flexible. The only place it is more difficult in the parent-child relationship.

DNSCuve would have horrible political problems. DNSSEC is currently waiting on political, not technical issues. You think the current squabble over who holds the signing key is bad? With DNSCurve, you HAVE to put the signing key online at every root server. In DNSSEC, you have the root signing key in a hardware key holding box, and put armed guards around it. One of these is massively more secure then the other. If that root key is compromised, DNSSEC has ability to cleanly roll over to a new key with a prepublish scheme, DNSCurve do to its simplicity has no mechanism.

DNSCurve seems like a good idea due to its simplicity, but DNSSEC can have similar simplicity with the right tools, but also has the flexibility to adapt from that easy, low maintenance but less secure deployment to high-security and guys with guns deployment. DNSCurve fails because if its simplicity and inflexability

All in all, DNSCurve is where DNSSEC was 10 years ago, with a cool idea but not covering all the use cases needed. Sorry, but DNSSEC does what we need, and it does it now.

Remember: The recent DNS bugs were predicted over a decade ago. The BIND group said don't worry, we'll have DNSSEC done soon, but other DNS server vendors (all those not based on BIND) adopted the very simple method of being immune to them.

No one had simple ways of being immune. 2 vendors had the port randomization turned on, far from everyone not BIND. It was a smart hardening step, but it doesn't make them immune to the currently known attacks. If it did, we wouldn't be having this conversation.

Re:Misreported

[mrsbrisby]

I think you overestimate the value of having the signing key on a different machine.

The hypothetical attack where an attacker secretly changes some records on a content DNS server is unlikely, and there's nothing that says it has to be any less likely than breaking the machine with the signing key on it.

Meanwhile, denial of service attacks occur all the time.

It seems naive to protect against the attacks that don't happen, and ignore the attacks that do.

More importantly, you also seem under the impression that DNSSEC is "extensible". It isn't. Any extensions to DNSSEC will require software and hardware changes on a scale similar to deploying DNSSEC the first time.

No one had simple ways of being immune. 2 vendors had the port randomization turned on, far from everyone not BIND. It was a smart hardening step, but it doesn't make them immune to the currently known attacks. If it did, we wouldn't be having this conversation.

DJBDNS ignores answers to questions it doesn't ask, which makes the attack practically impossible to launch; you only get to try to load bogus data in when the TTL of the NS is expiring, which simply doesn't happen that often on the default configuration.

Port randomization is just another example of how the BIND group doesn't "get it". Port randomization would slow this, and stop many other attacks, and yet the BIND group chose increasingly complicated non-solutions. Doing the simple things (ignore answers to questions not asked, port randomization) would have stopped this.

Re:Misreported

[Anonymous Coward]

djb hasn't submitted a draft of it to the IETF, hence, its not one of the solutions that the IETF is pursuing.

Re:Misreported

[Chris Burkhardt]

Thanks, that's really what I meant to ask. I found this thread on the IETF namedroppers list:

Re: Some notes on DNSCurve

Re:Misreported

[Cajal]

DNSSEC is supported by Unbound and NSD. Microsoft is adding support into Windows 7 / Windows Server 2008 R2, as well.

Re:sounds familiar

[CecilPL]

You mean the International Essential Tremor Foundation? Did I miss something?

Risk/Reward, other options

[gschwim]

Risk/reward also needs to be considered as part of this. The move to DNSSEC may itself be straightforward (emphasis on "may), but it does stand to increase overall DNS bandwidth and use of other resources throughout the global DNS infrastructures. Service providers are sure to look at this and wonder what they're getting out of the deal for their added costs.

One thing to consider as well is that DNS is not intended to be an authentication of a site you are visiting. It seems to me there are other methods of site validation (SSL/Certs).

Re:sounds familiar

[hairyfeet]

I thought it was Internet Explorer Trojan Foundation. And you have to admit that foundation HAS been working overtime, considering how quickly you get a Trojan if you use Internet Explorer. Now THAT is what I call service!

Minneapolis?

[Kohath]

We're trusting Internet security to people who don't know any better than to schedule meetings in Minneapolis in the winter. It's 17 degrees and very windy out right now.

Re:Minneapolis?

[Al Dimond]

I don't know much about this sort of thing, but I bet it's relatively cheap to book in cold-weather cities in the winter.

As a side benefit, it annoys Californians. Win all around.

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

Re:That's plain wrong

[Opportunist]

If that is so, I ask you to explain the success of Microsoft Software.

Re:sounds familiar

[Anonymous Coward]

You mean the Internal Explorer Trojan for Fucking?

Re:sounds familiar

[mellon]

Trust me, there's very little need for Trojans at a typical IETF meeting.

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.

Re:Emphasis on *amateur*

[mrsbrisby]

Heck, you do all the crypto off-line, so you can pick a big one.

Bzzt. Wrong.

Caches still have to verify the packets.

DNSCurve and DNSSEC have complementary security goals.

DNSSEC was designed by the same people who created the problem. Yet they keep saying "trust us, we've been doing this for a while".

DNSCurve was designed by cryptographers who went out to solve an actual problem that people are experiencing.

You on the other hand, are doing a lot of hand waving: You clearly don't have even a basic background in cryptography, and you're wrong about basic and simple things. Anyone paying you for advice is an idiot.

Seriously, how the fuck could anyone thing DNSSEC could protect anyone from anything if it really were "completely off-line"?

Re:Emphasis on *amateur*

[jonaskoelker]

Seriously, how the fuck could anyone thing DNSSEC could protect anyone from anything if it really were "completely off-line"?

Off-line means "not while it's happening".

As in, the protocol is NOT: get a request, sign something, send a reply (including a signature). The protocol IS: sign something, get a request, send a reply (including a signature).

The "sign something" step can be done on a different CPU, such that the name server doesn't have its CPU load increased. Signing doesn't introduce delays that weren't there in insecure DNS.

Here's how it protects you: you get the reply, and the signature, and then you validate it. If it's invalid, throw it out and goto 1. That way, you're protected against forgeries, assuming that signatures can't be forged.

Was it that unclear that this is what I meant by "off-line"?

you're wrong about basic and simple things.

Please give an example.

You clearly don't have even a basic background in cryptography

It's what I'm doing my phd in. Don't trust my arguments based on that; trust them on their own merit, and give good counterarguments.

This is one:

Caches still have to verify the packets.

Ah, true. Make the keys really big, not insanely big ;) and set a reasonable TTL so that that caches won't have to do this often [IIRC, signatures except NSEC records can be cached in DNSSEC].

This is not one:

DNSSEC was designed by the same people who created the problem. Yet they keep saying "trust us, we've been doing this for a while". DNSCurve was designed by cryptographers who went out to solve an actual problem that people are experiencing.

Here's slant in the other direction: DNSSEC was designed by people who know DNS intimately and know the operating requirements of critical infrastructure. DNSCurve was designed by people who were only considering the cryptographic aspects of security.

I'm not sure it's true, but I am sure that we should judge each solution on merits rather than on who's been designing them.

I'm sure DNSCurve has some good ideas in it. I'm also sure DNSSEC has some good ideas in it. I think we should find out what the good ideas are, which are most important, and then use that to judge each of the proposed solutions on their own merit. Maybe a combination of the best of both worlds is possible to an extent?

Re:sounds familiar

[Tubal-Cain]

Internet Exploder [is] Totally ------

arstechnica only reports what others noted already

[Anonymous Coward]

And, as usual, arstechnica is only spitting back information someone else already long ago noted and commented upon. That is what you get from a website that has people "reporting" for them that do not have years to decades of actual hands on experience in the trenches doing jobs in this science, nor do they possess degrees related to computer sciences. Classic case in point there is Jeremy Reimer, for one. This makes them good? No, I know not. They're just rephrasing what others long ago wrote and calling it their own.