Kaminsky Bug Options Include "Do Nothing," Says IETF 134
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.
DNS (Score:5, Funny)
Re: (Score:2, Informative)
It looks like you mixed up the resolver and the client.
Re:DNS (Score:5, Funny)
To know recursion, you must first know recursion.
Re: (Score:3, Funny)
Consider my mind officially blown.
Re:DNS (Score:5, Funny)
You keep that up, I might just blow my stack.
Re: (Score:2)
Why is this troll? This is some funny shit and does seem to be largely accurate.
DNS to slashdot has been hacked .... (Score:3, Funny)
and I am reading the wrong site. The aliens can return the real slashdot now. Surely IETF would never choose to "Do Nothing" :-)
Re: (Score:2)
Re: (Score:2)
So what powers does the IETF have on this? (Score:3, Interesting)
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? (Score:5, Interesting)
No one likes patching sinking ships but it's better than nothing. Doing nothing and waiting for DNSSEC are nearly the same thing.
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Well, they don't support some other as-yet-nonexistent alternate security fix for the Kaminsky Bug, either.
Re: (Score:3, Insightful)
Re:So what powers does the IETF have on this? (Score:4, Informative)
I guess we have different definitions of "exists", unless you mean it exists as a list of as yet unsolved problems.
Re: (Score:3, Informative)
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: (Score:2)
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.
The entire country, nay the entire world, would li
Re:So what powers does the IETF have on this? (Score:4, Informative)
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.
Re: (Score:3, Interesting)
Like for example, dnscurve [dnscurve.org], 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 wi
Re: (Score:3, Insightful)
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
Re: (Score:2)
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 a
Re: (Score:3, Insightful)
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: (Score:2)
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: (Score:3, Interesting)
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: (Score:2)
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: (Score:3, Informative)
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 w
Re: (Score:2)
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 disapp
Re: (Score:2)
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: (Score:2)
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.net], DNSSEC was started in 1993. That's far longer than a decade.
2. A controlled, toplevel deployment of DNSSEC to .SE
Re: (Score:3, Interesting)
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 g
Re: (Score:2, Funny)
Re:How many legs does the Kaminsky bug have? (Score:5, Funny)
It's a space station. You don't need a vacuum cleaner. Just open a window.
Re: (Score:2)
Re: (Score:2)
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? (Score:4, Funny)
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: (Score:2)
Groan!
Re: (Score:2, Funny)
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: (Score:2)
Old news? (Score:4, Informative)
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 [arstechnica.com]
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: (Score:2)
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: (Score:3, Informative)
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.
Stupid, stupid, stupid! (Score:5, Insightful)
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: (Score:2)
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
Re:Stupid, stupid, stupid! (Score:4, Informative)
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: (Score:2)
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 pri
Re: (Score:3, Insightful)
Actually, there are a lot more than two major holdups:
Re: (Score:3, Interesting)
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 who
Re: (Score:2)
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 DNS
Re: (Score:2)
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 thi
Re: (Score:2)
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 t
Re: (Score:2)
Re: (Score:2)
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 pr
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Which is to say, no, that attack won't work for any sane deployment.
Re: (Score:2)
The last thing I expected is that spam would "run rampart".
Re: (Score:2)
chinese farmers = spam and they are running ramps for loots....
Re: (Score:2)
If that is so, I ask you to explain the success of Microsoft Software.
Re: (Score:2)
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.
Translation.... (Score:2)
"Do nothing"
After applying CIS and corporate-speak filters:
"Aw man, do I have to get up and actually program some code?"
sensationalist nonsense - use 0x20 now! (Score:5, Interesting)
Stupid sensationalism.
You can right now use draft-vixie-dnsex-dns0x20 [ietf.org] to protect against the kaminsky bug. This option is already available in the unbound [unbound.net] 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: (Score:2)
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: (Score:2)
Re: (Score:2)
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 r
Re: (Score:2)
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!
DNSSuCk? (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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 [cr.yp.to].
5. I'm leaving this one alone.
6. CA certificates were planned for an earlier incarnation of DNSSEC
7. I don't think thi
Misreported (Score:5, Informative)
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: (Score:2, Interesting)
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: (Score:3, Interesting)
Is DJB's DNSCurve [dnscurve.org] a viable solution?
Re: (Score:2)
But that's just personal bias.
Re: (Score:2)
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 standardi
Re: (Score:3, Interesting)
I disagree. DNSSEC isn't widely implemented, and the widest test [64.233.169.132] 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.
Re: (Score:3, Informative)
I disagree. DNSSEC isn't widely implemented, and the widest test [64.233.169.132] 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 all
Re: (Score:2)
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.
I'll highlight it for you:
Availability
Re: (Score:2)
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
Re: (Score:2)
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 th
Emphasis on *amateur* (Score:4, Interesting)
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: (Score:2)
Bzzt. Wrong.
Caches still have to verify the packets.
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
or else what?
Re: (Score:2)
they cant use the internet. make it not backwards compatible....
Re: (Score:2)
Re: (Score:2)
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 Win95
Minneapolis? (Score:2)
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? (Score:4, Funny)
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? (Score:4, Interesting)
Minneapolis has a "Skyway." [downtownmpls.com] 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? (Score:4, Interesting)
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: (Score:3, Funny)
*whoosh*...
You really should have your humor circuits checked you know ?
YHBT
Re: (Score:2)
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 ;) )
Re: (Score:2)
Re: (Score:2)
Re:sounds familiar (Score:4, Funny)
Trust me, there's very little need for Trojans at a typical IETF meeting.