×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Kaminsky On DNS Bugs a Year Later and DNSSEC

CmdrTaco posted more than 4 years ago | from the i-feel-safer-already dept.

Security 127

L3sPau1 writes "Network security researcher Dan Kaminsky has had a year to reflect on the impact of the cache poisoning vulnerability he discovered in the Domain Name System. In the time since, Kaminsky has become an advocate for improving security in DNS, and ultimately, trust on the Internet. One way to do this is with the widespread use of DNSSEC (DNS Security Extensions), which essentially brings PKI to website requests. In this interview, Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

127 comments

new security products and services? great. (0, Flamebait)

Anonymous Coward | more than 4 years ago | (#28466531)

I have never met a bigger group of shysters and con-artists than "security consultants" in all my life.

Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services

that says it all, right there. This isn't about securing your assets, this is about generating fear so an army of security consultants can sell you an entirely new class of products you don't need.

Re:new security products and services? great. (4, Insightful)

i.r.id10t (595143) | more than 4 years ago | (#28466581)

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

Re:new security products and services? great. (5, Insightful)

gandhi_2 (1108023) | more than 4 years ago | (#28466633)

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

Sincerely,
Both Political Parties.

Re:new security products and services? great. (0)

Anonymous Coward | more than 4 years ago | (#28473007)

I guess the US screwed itself up with bi-partisan system.

Re:new security products and services? great. (5, Insightful)

headhot (137860) | more than 4 years ago | (#28466723)

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

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

Re:new security products and services? great. (-1)

Anonymous Coward | more than 4 years ago | (#28466789)

DNS needs to be secured.

Or the technically illiterate need to be severely beaten about by a clue stick until they learn how to read a domain name?

"No, you moron, yourbank.scammerdomain.com is not really yourbank!" *POW* "Now stop contributing to insecurity!" *BAM*

Re:new security products and services? great. (5, Informative)

headhot (137860) | more than 4 years ago | (#28466807)

This is not how the kraminisky bug works. You can intercept and redirect traffic with a properly formed DNS label to a legitimate site.

Re:new security products and services? great. (0, Interesting)

Anonymous Coward | more than 4 years ago | (#28468455)

I don't care if you really did invent the Internet.. This does not make DNSSEC any less of a retarded idea.

The Internet can not be free and trustworthy at the same time. Keeping the network dumb and the edges smart where trust is best positioned to be established is the only design decision not rooted in nonsense.

The problem with IETF standards process is that the realistic concept of "more is less" or "good enough" is constantly drowned out by the voices foolishly seeking to write the perfect protocol even if the result is unreasonable in practice or adds significant complexity and overhead without providing any tangable benefit in return.

The Internets DNS does *NOT* need to be secure -- It mearly needs to protect against everything short of an active MITM which requires less than an ounce of cryptography to implement effectivly.

Making the trust anchor so large that it encompasses the entire planet for a given tld is the very definition of futility. Some hacker or government somewhere will eventually get a root key and sign whatever domain they damn well please regardless of how careful and dilligent all of the players involed are.

Now for corporate/intranet environments DNSSEC has a great deal of value.

Re:new security products and services? great. (0)

Anonymous Coward | more than 4 years ago | (#28472433)

Now for government/military/spying DNSSEC has a great deal of value.

Fixed that for ya'.

Re:new security products and services? great. (3, Interesting)

Effugas (2378) | more than 4 years ago | (#28472999)

(This is Dan)

I actually completely agree with your desire to see trust in the edges. That's what's so interesting about DNSSEC -- DNS, by its very design, is all about getting the core the hell out of the way and delegating, delegating, and delegating some more until the organization that manages the namespace can directly control it.

Indeed, in the ultimate vision of DNSSEC, we have full on validating resolvers in clients. The endpoints themselves can finally - finally! - recognize their peers directly, without having to trust anyone or depend on the admitted messiness of the existing SSL CA infrastructure.

The reality about Active MITM is that it's out there. See the BGP work that came out in tune with my talk -- note that all that still works, today, even with my big fix. Active MITM isn't some theoretical attack, and the reality is that everything is vulnerable to it. An ounce of cryptography is worthless without a metric asston of key management. DNSSEC is just the best way I can see to do it.

Regarding the trust anchor size, the reality is that we have 25 years of it not being a problem. That's the simple truth. Everything I did last year could have been done by a malicious root. It wasn't.

Your corporate/intranet myth is funny, because it strikes at the heart of the problem. You think there's just one corporate/intranet to authenticate. It's literally like you're suggesting, email to other companies is complicated, so lets just do email to our own company. Nice, but not good enough. We need cross organizational trust. We need something to bootstrap it. DNSSEC should be that.

You obviously have no idea what your talking about (4, Informative)

gubers33 (1302099) | more than 4 years ago | (#28466761)

Do you even know what DNSSEC is? It is nothing he is trying to sell, it is him trying to completely take care of the flaw he found in DNS last summer. A flaw that could have seriously fubared the net if he didn't go through massive patching with internet providers and large companies. So you know, just about all DNSSEC software is opensource, meaning it is free. He isn't a conartist and it is pretty ignorant to call him one, he spent countless hours last summer trying to get the patch out which he didn't make money off of since he released it for free.

Re:You obviously have no idea what your talking ab (0, Interesting)

Anonymous Coward | more than 4 years ago | (#28466875)

http://it.slashdot.org/comments.pl?sid=1134339&cid=26924561

So, did Kamisky find a flaw in dns, or just bind? He's a blowhard.

(I'm not #1311235)

Re:You obviously have no idea what your talking ab (0)

Anonymous Coward | more than 4 years ago | (#28473449)

In BIND and a few others. But others again, like powerdns, already did the suggested randomization.

It's really in DNS - BIND etc. were workarounds (4, Informative)

billstewart (78916) | more than 4 years ago | (#28475345)

The flaw is really in DNS - the only authentication field in a DNS request is a 16-bit query id, plus the implicit authentication of a 16-bit port number, and IIRC correctly you could also birthday-attack the query-id. Kaminsky's changes to DNS implementations such as BIND (which was build into djbdns etc. since the beginning) get you a few more bits of protection against an attack, but that just means that DNS is "still pretty weak" as opposed to "really really weak".

And unfortunately, IPv6 DNS is no better - it keeps the same basic header for compatibility, adds some new longer record types, and adds some 128-bit addressing, but the QueryID's still the same old 16 bits.

DNSSEC gets to the root of the problem, with cryptographic signatures on the data. It may be overkill compared to just putting in a 128-bit or 256-bit Query-ID field, but basically it's something that's possible actually get deployed, because it's a set of additional data transported in DNS, not a replacement for DNS's transport protocols. The reasons it wasn't done years ago have a lot to do with the NSA/FBI anti-crypto policies of the 90s, and Verisign's reluctance to do a huge amount of work nobody cares about to protect .com, but we're finally getting the root signed.

Re:You obviously have no idea what your talking ab (0, Interesting)

Anonymous Coward | more than 4 years ago | (#28467227)

No, but he did get tons of publicity for a design bug that has been known about since the early 2000s. http://cr.yp.to/djbdns/forgery.html [cr.yp.to]

Re:You obviously have no idea what your talking ab (1)

gubers33 (1302099) | more than 4 years ago | (#28468539)

Cache Poisoning has been around for years, using in the manner he did has not.

Re:You obviously have no idea what your talking ab (1, Interesting)

Anonymous Coward | more than 4 years ago | (#28468997)

DNSSEC must be the most wildly overrated technology to ever come out of the internet.

Seriously, it's just terrible from a system administrator's perspective.

It's been a year since I listened to a speech about DNSSEC (from an official ISC representative) at a Linux User Group meeting, so I don't have every last detail on the tip of my brain. However, it provides a little more security in some ways, while making other things worse.

Among the highlights:

- You need to sign your DNS zones every thirty days or so, because the crypto in DNSSEC isn't really that good for speed optimization reasons

- If the signatures on your DNS zones expire, any validating DNSSEC resolver will pretend like your zone doesn't exist (since it was too late to use anything other than NXDOMAIN to indicate signing problems to keep backwards compatibility)

- You therefore need to set up a cron job on a second server to make sure that the DNS zones were signed properly. At the time this bug was published, there weren't any tools to do this in a sane manner, so you'd have to write your own scripts

- If you are an ISP, running a validating DNSSEC compatible resolver will likely end in more customer complaints, since it treats signed-but-expired DNS zones as NXDOMAIN, whereas a standard DNS setup would continue to work. Paul Vixie himself ran into this problem with one of his domains, forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.

- As one of the new requirements of DNSSEC, it is now impossible to not publish a list of every single subdomain on your DNS zone. This is because every record in the zone has a pointer to the next record, kind of like a circular linked list. ISC maintains that this is no big deal, but there are plenty of people (myself included) that feel otherwise.

- The root and second level DNS providers are probably not going to support DNSSEC, or at least that was the feeling a year ago. As a result, ISC came up with something called DLV, or Domain Lookaside Validation (RFC 5074). This essentially sets up ISC as the official arbiter of which second level DNS zones (like google.com, microsoft.com, etc) are official and can sign their own zones.

ISC may not be selling anything, but they stand to gain significantly if they become the de facto authority on which internet domains are valid, and the presentation was more full of FUD than anything I had ever heard come out of Microsoft. Seriously.

I got the strong feeling that DNSSEC in general really feels half baked and rushed out, rather than something simple and well thought out. I would advise everyone to avoid it like the plague, and hold out for a better solution.

Re:You obviously have no idea what your talking ab (4, Informative)

Effugas (2378) | more than 4 years ago | (#28473049)

(This is Dan)

Trust me, I'm raising more hell than you can imagine about the deployment issues of DNSSEC. Here's the truth:

1) You don't actually need to do all that resigning stuff. When best practices involve increasing your costs 100x, something is wrong.
2) You don't actually need to have your signatures expire.
3) You don't actually need that cron job.
4) They fixed that zone walking problem with NSEC3. If you have online keysigning, which I expect everyone to have, you don't even need that.
5) .org is signed. .com is coming, as is the root itself. Things have changed.

Standby. Seriously, this is coming, and it's not going to be miserable by the time you actually need to deploy it.

Re:You obviously have no idea what your talking ab (0)

Anonymous Coward | more than 4 years ago | (#28473253)

- If you are an ISP, running a validating DNSSEC compatible resolver will likely end in more customer complaints, since it treats signed-but-expired DNS zones as NXDOMAIN, whereas a standard DNS setup would continue to work. Paul Vixie himself ran into this problem with one of his domains, forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.

False. The recursor will also return SERVFAIL.

- As one of the new requirements of DNSSEC, it is now impossible to not publish a list of every single subdomain on your DNS zone.

False. Look up NSEC3.

- The root and second level DNS providers are probably not going to support DNSSEC, or at least that was the feeling a year ago.

Yeah, that was a year ago. Search Slashdot for announcments of TLDs and even the root that they support DNSSEC or will do so in the close future.

Re:You obviously have no idea what your talking ab (2, Insightful)

jafiwam (310805) | more than 4 years ago | (#28469149)

You don't host anything for real paying customers do you?

Let me give you a summary of how interaction with "security consultants" usually goes:

1. Customer gets cold called or sees some FUD on local TV, or portscans or the "consultant" has some dude in Malaysia digging around to find the sites hosted for pennies an hour.
2. Customer gets bilked out of a couple hundred dollars for a 'security audit' (a scan using a common tool with default settings usually)
3. Customer fails to understand any of it.
4. Passes a FUD report on to my desk, and proceeds to piss and moan or wring hands.
5. I have to stop what I am doing and examine the bogus report, then make a time consuming write up, explaining why having port 80 open is not a big deal and that it's typically not possible to be running both IIS and AIX (Unix) on the same box.
6. "security consultant" either tries to sell the user a open source program, Barracuda box (puke) or just laughs all the way to the bank, or even better yet starts bugging me about being honest with the customer (who is now unhappy about the fee charged).

This sequence repeats with every new BS bug, news story, or any time the economy is flush with IT money.

The "security consultant" is never really concerned about security, only money. Most of the time they don't know anything, sometimes they are outright brain-dead stupid and want to do things like put a notice "Please do not hack our web site" on every page because they think it won't be illegal to deface if the notice is not there. (Yes, that's really what they wanted.)

Replace the "security consultant" with the following types; "copyright protection scanning" and "defacement warning monitoring" (THAT is a bullshit scam) and "version back ups" and you have a whole world of suck. Thankfully the economy has been bad for a while so mom&pop shops are slamming the door on a two hundred dollar expense for an audit.

Maybe Kimansky himself won't be doing this, however a legion of other folks will be following shortly behind that will. The dream to update DNS is nice, but it's a stupidly impractical thing to be demanding everybody do right now. Aside from a few articles here and there, the "real world exploits" for this stuff, where someone actually gets harmed... well, where are THOSE reports?

Re:You obviously have no idea what your talking ab (1)

BigHungryJoe (737554) | more than 4 years ago | (#28469335)

Aside from a few articles here and there, the "real world exploits" for this stuff, where someone actually gets harmed... well, where are THOSE reports?

Since Dan Kaminsky is active in this thread, I'd love to see him answer this question. I'm guessing he's probably bound by non-disclosure agreements and can't give us any details, but I'd like to know if he's seen succesful, real-world attacks out "in the wild" that resulted in real damage done.

Re:You obviously have no idea what your talking ab (4, Informative)

gubers33 (1302099) | more than 4 years ago | (#28470045)

The DNS cache poisoning attack was used the same week it was put into metasploit on a Verizon DNS in Texas where the attacker was forwarding people to a fake Google page with malware on it. Just one I can recall from when this first came out.

Re:You obviously have no idea what your talking ab (3, Interesting)

Effugas (2378) | more than 4 years ago | (#28473103)

(This is Dan)

There's lots of shysters in every field. Doesn't change the fact that there are problems out there that need fixing. Security is in fact a problem.

In concrete terms, just for my vuln, about 1% of one of Brazil's largest bank's customers had their info taken by my bug. That wasn't fun. And China Netcom got hit pretty hard too, go Google that. Of course, there's a lot of data we're missing, because nobody needs to report. But anecdotally, this was a problem, but not the end of the world. Good! I didn't exactly set out to end the world :)

In terms of what I see fixing, I see a lot of technologies repeatedly sold as "and then you get certificates", and nobody does, because it's just such a cross organizational nightmare to manage. Certs aren't working, and it's holding back auth technology after auth technology. Verizon Business' data says that 60% of vulns aren't implementation flaws -- they're authentication flaws, with passwords at the heart of them.

Why so many passwords? Because they work. Well, DNS works too. Maybe we can use it to make all the better things scale across organizational boundaries.

Re:new security products and services? great. (4, Informative)

Effugas (2378) | more than 4 years ago | (#28466797)

(This is Dan)

No, it really is about securing your assets, instead of trying to deploy yet another magic box that conveniently fails just as you try to get it out of testing.

Question to you Mr. K. ... apk (0)

Anonymous Coward | more than 4 years ago | (#28469259)

Well, I think you've done a GREAT job, & the fools that are attempting to "put you down" here are only botmasters/malware makers/"hacker-cracker" types were I to judge they (& yes, I am with that statement)... so, so much for them.

From my side of the playing field, & in regards to your efforts + findings?

Well - Your findings have helped me strengthen the case(s) I have that favor customized HOSTS files in fact!

I say that, because until you really CAN fully trust DNS servers & their returned data over port 53 udp requests (the case for most folks, as most do not have DNS servers of their own doing zone transfers over tcp)?

Your findings + efforts to stop that have opened MY EYES & those of others as well, as to problems in the Domain Name System... & thus, this IS a case (not just the added speed) for doing hardcoded IP-to-URL equations in a HOSTS file, so you don't HAVE to perform those types of queries (& who knows if they CAN be trusted, & are not DNS poisoned misdirects)...

I also believe it can stop/stall what is going on over in Germany lately, per this article here from the other day -> A Black Day For Internet Freedom In Germany
http://slashdot.org/comments.pl?sid=1270901&cid=28364263 [slashdot.org] as well, & per my comments there in that url?

In fact, in regards to the points I put up there? You're JUST THE GUY I WOULD LIKE TO SEE HIS VIEWS ON THAT & THE POINTS I BROUGHT UP THERE IN IT...

Thanks!

Sincerely,

APK

P.S.=> Keep up the good work, as cliche as that sounds... you're doing great, & for what appears to be solely for the good of others, & out of the kindness of your own heart - if the world had more folks in it of THAT nature? It'd be a better place! apk

Re:Question to you Mr. K. ... apk (-1)

Anonymous Coward | more than 4 years ago | (#28470615)

He's not going to let you suck his cock, no matter how much asslicking you do.

Sorry to disappoint you, I'm not into that stuff! (0)

Anonymous Coward | more than 4 years ago | (#28471365)

"He's not going to let you suck his cock, no matter how much asslicking you do." - by Anonymous Coward on Thursday June 25, @03:28PM (#28470615)

Sorry to diappoint you, but I am not a homosexual - so, go find another dish: I'm NOT on the "menu"...

APK

P.S.=> Trolls - TOO easy to "put in their place", lol... apk

Re:new security products and services? great. (0)

Anonymous Coward | more than 4 years ago | (#28467785)

This isn't about securing your assets, this is about generating fear so an army of security consultants can sell you an entirely new class of products you don't need

Yea, just like I hate how microsoft is trying to sell me crap I don't need every other Tuesday with their hotfixes and... oh, those are free? just like dnssec? hmm

So, what is being sold again?

Optimistic guy (4, Funny)

mtremsal (1554627) | more than 4 years ago | (#28466687)

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

You just think that way because you haven't been.. (5, Insightful)

brunes69 (86786) | more than 4 years ago | (#28466765)

.. hit yet.

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

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

A: because it breaks the flow of a message (3, Insightful)

DNS-and-BIND (461968) | more than 4 years ago | (#28470739)

Q: Why is starting a comment in the Subject: line incredibly annoying?

Re:You just think that way because you haven't bee (1)

BikeHelmet (1437881) | more than 4 years ago | (#28472575)

Yes, this oten means investing time and money in something that has no immediate ROI. But that is the nature of the problem you are dealing with.

Not only that, but if you invest and it actually works, you get the impression you wasted money, because nothing happens. :P

It's the same thing with Global Climate Change. If we actually fight it tooth and nail, the best we can hope for is no change from the present. Hardly a reward! ;)

Re:Optimistic guy (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#28466787)

Sadly, I'm willing to agree. DNSSEC may, in fact, be the cat's meow and and end-all-be-all to security, everywhere, but the way Kaminsky's advocating it seems disturbingly similar to some raving lunatic who finally, by a dumb stroke of luck, got one doomsday prediction right (in some way, shape, or form), and is now running around to anyone who'll listen, punctuating all his arguments with "Oh yeah? Well, I was right about DNS security! Remember? REMEMBER THAT, SONNY??!? I WAS RIGHT AND EVERYONE ELSE WAS WRONG SO LISTEN TO ME BECAUSE I KNOW MORE THAN YOU DO."

Re:Optimistic guy (4, Informative)

Effugas (2378) | more than 4 years ago | (#28466937)

(This is Dan)

Well, I was one of the guys who was wrong (about DNSSEC, anyway) so it doesn't completely match up.

Look, simple question: Do you think the existing system, of X.509 certificates, of SSL CA's, of private PKI's, is at all working? I sure don't. All I see are crappy passwords everywhere, being left as default, getting leaked, being brute forced, etc. Most security technology isn't working.

DNS works well. Seems to me more things should work like it.

Re:Optimistic guy (1)

causality (777677) | more than 4 years ago | (#28467463)

I find the (Slashdot) story title and summary to be a bit misleading, though I doubt that was intentional. As a result, I think most of the replies to you fail to appreciate that you are not really talking about fixing a flaw in DNS; you are talking about using DNS as an infrastructure to make many more things start depending on it. From TFA:

DNSSEC is interesting not because it fixes DNS. DNSSEC is interesting because it allows us to start addressing core problems we have on the Internet in a systematic and scalable way. The reality is: Trust is not selling across organizational boundaries. We have lots and lots systems that allow companies to authenticate their own people, manage and monitor their own people and interact with their own people. In a world where companies only deal with themselves, that's great. We don't live in that world and we haven't for many years.

And:

DNS has been doing cross-organizational address management for 25 years; it works great. DNS is the world's largest PKI without the 'K.'All DNSSEC does is add keys. It takes this system that scales wonderfully and has been a success for 25 years, and says our trust problems are cross-organizational, and takes best technology on the Internet for cross-organizational operations and gives it trust. And if we do this right, we'll see every single company with new products and services around the fact that there's one trusted root, and one trusted delegating proven system doing security across organizational boundaries.

That seriously sounds like a single point of failure. Please explain to me why that's not a bad idea? Or to put that another way, what happens when this "one trusted root" is finally compromised? I imagine that it would be a most attractive target.

It's 2009 and we don't have secure email. When we get DNNSEC, we will be able to build secure email and secure technology up and down the stack and it will scale.

Please speak for yourself. Cryptography and Open Source have provided the means for both secure and securely authenticated e-mail for years now. Anyone who wants to use those tools can get them, so I am forced to conclude that whether it's right or wrong, most people just don't care about secure e-mail (I wish they did but forcing it on them would be wrong). So, what do I gain by giving up gnupg/enigmail and replacing it with more dependence on DNS?

Re:Optimistic guy (3, Interesting)

Effugas (2378) | more than 4 years ago | (#28467685)

(This is Dan)

Sure, DNS is a single point of failure with security implications. What else is new? Half my talk last year showed what sort of damage you could do if you could corrupt any DNS name. The root can, today.

It also scales really, amazingly, wonderfully well. See, DNS actually delegates, unlike X.509. That means the root doesn't interact with most people, just a few countries and gTLDs.

So, how many people do you have in your GPG keyring? Few dozen? Few hundred? I spent six months interacting with people over email securely. It added an average of 72 hours of time before work could be done, and often it didn't work. C'mon, this ain't scaling.

Re:Optimistic guy (1)

causality (777677) | more than 4 years ago | (#28468783)

Sure, DNS is a single point of failure with security implications. What else is new? Half my talk last year showed what sort of damage you could do if you could corrupt any DNS name. The root can, today.

I guess what I am asking is this: such a failure that results in corrupting a DNS name is already bad enough. Would it not be worse if many other security mechanisms also depended on it?

What makes DNSSEC better than using protocols (such as SSH) which can independently verify the identity of a host by means of cryptographic signatures? This to me also seems consistent with the idea that good security is done in layers, not by single ultimate solutions.

So, how many people do you have in your GPG keyring? Few dozen? Few hundred? I spent six months interacting with people over email securely. It added an average of 72 hours of time before work could be done, and often it didn't work. C'mon, this ain't scaling.

Actually with the Enigmail plugin for Thunderbird, I can check the public key servers to quickly add anyone's key to my keyring with two mouse clicks. I believe this option shows for any e-mail that is cryptographically signed. Thus, the current size of my keyring is much less important to me than the ease by which it may be dynamically expanded on an as-needed basis. So my answer is that at least in my experience, this has never been a problem for me. Thus, for me, the ways that DNSSEC would address this amounts to a solution looking for a problem. I admit that I may be an unusual example though if so, I'd be interested in why it isn't so simple for others.

I am curious as to why you had so many problems with gnupg (you did not specify). Is that because you have found identifiable design flaws in gnupg, or is it because of user error on the part of folks with whom you were communicating? If the problem was user error, which is people working with what they do not understand, will a centralized security mechanism automatically fix that, or will it merely replace one thing they do not understand with another? I am rather skeptical of any attempts to solve problems caused by user error that don't actually seek to train those users, as this seems like an unwillingness to address the actual problem. That's especially true for security, which among all issues is one of the most unforgiving of ignorance or incompetence.

Re:Optimistic guy (1)

rho (6063) | more than 4 years ago | (#28470723)

Actually with the Enigmail plugin for Thunderbird, I can check the public key servers to quickly add anyone's key to my keyring with two mouse clicks.

Actually, when a nerd starts using his personal desktop experience as a rebuttal to a large-scale engineering problem, you know the logic car has just driven off into the weeds.

Put another way--how would you like to be the guy who does "two mouse clicks" for, say, the Hotmail email servers? (If you so much as mention using a Perl script to handle it I will reach through the Internet and choke you.)

Re:Optimistic guy (2, Interesting)

Effugas (2378) | more than 4 years ago | (#28473195)

What makes DNSSEC better than using protocols (such as SSH) which can independently verify the identity of a host by means of cryptographic signatures? This to me also seems consistent with the idea that good security is done in layers, not by single ultimate solutions.

I don't mind SSH, with its key caching, but what about initial trust? What about the fact that, in the real world, keys change (just like IPs change) and when they do, something needs to say the new content is OK? It'd be nice to have a system that existed independent of any given server, which could (through a *delegated chain that didn't require cross-organizational begging*) assert the validity of new content.

The root servers were there 15 years ago. They'll be there 15 years from now. That's a fantastic foundation to build just what we need.

I am curious as to why you had so many problems with gnupg (you did not specify). Is that because you have found identifiable design flaws in gnupg, or is it because of user error on the part of folks with whom you were communicating?

It's because the PGP keyservers get stale data, and the entire revocation system doesn't work. I have multiple keys in there I can't get rid of, because I don't have a business relationship that lets me identify myself and I don't have the key material to eliminate the key. Go look through the data, it's a mess.

In the end, the keyservers work better than web of trust, but not much better.

None of it as implemented is about security (1)

TheLink (130905) | more than 4 years ago | (#28467965)

> Do you think the existing system, of X.509 certificates, of SSL CA's, of private PKI's, is at all working? I sure don't.

I don't, IMO they are just a way for Verisign and Friends to collect toll.

But I don't see how DNSSEC fixes that at all, it just makes it easy for Verisign et all to collect yet more toll.

If people were really interested in security they would have the https cert stuff behave a bit more like ssh does, e.g. if the browser notices the cert for myfavbank.com has changed, and now signed by a different CA (from Elbonia ;) ) even though the cert is valid the browser should give a warning. Wouldn't you want to know if your bank's cert's CA was suddenly changed from one CA to another CA even though the original cert still had 1+ year left to go? But as far as I know, none of the browsers do that.

In practice there really is little difference between a self signed cert and one signed by a CA. Like you said - crappy passwords everywhere, and CA's signing stuff blindly. Self signed certs are vulnerable on the "first time", or if/when the cert expires. CA signed certs as currently implemented are vulnerable to the "some idiot CA being tricked/hacked" attack.

Hardly anyone cares, they leave scores of CA certs (30+?) in their browsers, CAs that they don't know at all. And all the certs are left there because people don't want the browser to pop up warnings and "inconvenience" users. And that's the same reason why people pay the CA's money to sign their server certs. It's not about security at all.

Call me cynical, but I feel the same about DNSSEC. Just looking at the complexity and the way it works. It's for collecting toll ala CAs, and it's for making things more complicated so that people can make $$$ from consultancy and support.

But on the bright side I might return to that line one day ;).

Re:None of it as implemented is about security (1)

Lennie (16154) | more than 4 years ago | (#28468613)

Have a look at the Firefox Perspectives add-on, it's meant for telling you when a self-signed cert changes, but can also be configured for use with normal certs.

Re:None of it as implemented is about security (1)

Effugas (2378) | more than 4 years ago | (#28473241)

(This is Dan)

If I get a cert for www.doxpara.com from a CA, I need to get another cert for mail.doxpara.com, foobar.doxpara.com, and so on (assuming I want one private key per server).

If I acquire doxpara.com from Verisign, I can handle the rest myself thank you very much.

It's a pretty major difference.

Also a major difference is the reality of who can screw you. In DNSSEC, you have to worry about your registrar (GoDaddy), your registry (Verisign), and the root. In x.509, you have to trust every CA in the world. Since people don't, they try to build their own private corporate PKI's. We see how well that goes...

Not to be too down on CA's -- they're critical for the work they're doing in EV, to deal with phishing attacks that DNS cannot stop -- but for foundational trust, DNSSEC is the path.

Re:None of it as implemented is about security (3, Insightful)

Tony Hoyle (11698) | more than 4 years ago | (#28476211)

You can get wildcard certs. for HTTP as well. They cost lots and lots of $$$

You wonder how much getting a domain signed is going to cost... thing Verisign is going to turn down a cash cow that big? I'd be surprised if they charge less than $1000 per domain.

Ultimately, as Verisign signs the root, all paths (and all money) leads to them - and that's why they're pushing DNSSEC so much.

Re:Optimistic guy (1, Interesting)

Anonymous Coward | more than 4 years ago | (#28468907)

How much network traffic will DNSSEC add to the network?

Minimal network traffic, except if you're root/com (1)

billstewart (78916) | more than 4 years ago | (#28475441)

DNS doesn't take up a lot of network bits - at the beginning of a data flow, you typically look up a DNS name to find the IP address, then start doing things, and even if all you're doing is a small text email or fetching a small text html page, the protocol headers alone are a lot bigger than the DNS query, and usually the data's a lot bigger. Changing to DNSSEC adds a few hundred bytes to that query, but it's almost always a drop in the bucket.

Of course, if you're a big name server, like one of the root or .com authoritative servers, or a big ISP's caching name server, that's different, since almost all your traffic is DNS. But that's not a lot of servers, though the overall load on them will obviously increase for a variety of reasons. On the other hand, if they get rid of DNS name kiting, a lot of the junk traffic will go down.

Re:Optimistic guy (3, Interesting)

askksa (1167121) | more than 4 years ago | (#28466865)

There are numerous issues with implementing DNSSEC. The idea has been around for like 14 years now. Also, there are alternatives like DNSCurve which provide more security with considerable ease of deployment.

Re:Optimistic guy (4, Informative)

Effugas (2378) | more than 4 years ago | (#28466903)

(This is Dan)

DNSCurve can't achieve end-to-end security while still caching. Without the former, you're trusting the name server at Starbucks not to be malicious. Without the latter, there's a 10x (minimum) increase in DNS traffic and the internet collapses.

There's some really interesting math going on, but operationally DNScurve isn't a good path.

That being said, there are some really interesting things from DNScurve we can integrate into DNSsec without any code mods. Key rollover is a mess in DNSSEC, and it's somewhat unnecessary.

Re:Optimistic guy (0)

Anonymous Coward | more than 4 years ago | (#28467357)

Dan, you are the Man. .... I'm sure that's old but I don't care :)

Re:Optimistic guy (2, Interesting)

foom (29095) | more than 4 years ago | (#28467377)

I'm just going to repost my last comment on this subject. I don't think things have changed since then, but if they have I'd certainly be interested to know. :)

You might be interested in this thread:
https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html [dns-oarc.net]
where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. The only difference being that DNSSEC is hugely more complex to use and implement.

Re:Optimistic guy (2, Interesting)

Effugas (2378) | more than 4 years ago | (#28467695)

(This is Dan)

That's interesting if you're just trying to secure DNS. We have much bigger fish to fry -- fish that require us not trusting the NS at Starbucks.

Re:Optimistic guy (1)

foom (29095) | more than 4 years ago | (#28468249)

Huh?

DNSSec doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because you can't do DNSSec from a stub resolver and have to use TSIG (which protects the client->server data transfer, not the zone data).

DNSCurve doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because DNSCurve protects the client->server data transfer (of each step of the process) not the zone data.

You're screwed either way.

Or, you can decide to either use a different resolver somewhere on the internet you *do* trust (and configure its key so you can be sure you're actually talking to it!), or run a caching recursive resolver on your laptop. Either of those will give you properly secured DNS with both DNSCurve and DNSSEC.

Re:Optimistic guy (2, Interesting)

Effugas (2378) | more than 4 years ago | (#28473275)

(This is Dan)

Hehe. OK, I like you foom. Lets talk.

So the deal is, DNSSEC lets the server at Starbucks cache DNSSEC records for you. So even if it's not doing the validation, it can at least remember the crypto such that each backend host that is doing validation can enjoy the cached records on the shared NS.

You can't do that with DNScurve, since the crypto is link based.

I've been playing with the Curve25519 code lately. It's cool, I have use for it (understatement), and it's a joy to work with. But DNScurve has a design limit, and we need a little more than it can accomplish.

Re:Optimistic guy (1)

Tony Hoyle (11698) | more than 4 years ago | (#28476107)

DNSSEC has two big problems:

1. Without an unbroken chain of trust to the root, it's worthless. Self signed DNSSEC is no better than no DNSSEC.
2. It's vulnerable to MITM attacks - just strip the DNSSEC information from the returned packets and return a normal (modified) DNS reply.
3. Because of the chain of trust setting it up will cost $$$ - probably going to Verisign, as usual.
4. Until absolutely everyone in the world uses DNSSEC the fallback to normal DNS cannot be removed, so 2. remains a problem. 3. guarantees that this will never happen.

Re:Optimistic guy (1)

Tony Hoyle (11698) | more than 4 years ago | (#28476129)

Oh and I'd add the thing is f..ing *hideously* complex to setup, with multiple competing implementations that aren't compatible with each other because some have special DNS tags, some use TXT records, the formats keep changing, etc. Spent 4 days on it once.. I got maybe 10% of the available dnssec testers to even recognize that I implemented their brand of dnssec.

Re:Optimistic guy (1)

foom (29095) | more than 4 years ago | (#28476447)

A "validating stub resolver" will actually need to be (basically) a recursive resolver itself (it needs to do multiple queries to verify each signature in the delegation chain from the root down to the record it's actually interested in). And thus, if you want it to perform well, it'll need a local cache.

Now it's basically a caching recursive resolver.

So, is your claim that because the caching recursive resolver which you run on localhost can use a second-level remote cache instead of talking to the authoritative servers directly, DNSSEC is superior?

I suppose you can consider that an advantage...but heck, I sure can't see the point of it. If you're going to require a caching recursive resolver on localhost, just have it talk to the authoritative servers and be done with it... It certainly doesn't seem worth all the pain of DNSSEC to allow for an untrusted intermediate cache to be used!

I just don't see it.

Re:Optimistic guy (1)

Todd Knarr (15451) | more than 4 years ago | (#28467721)

The one difference is that in most cases the recursive resolver will be under the control of either the user themselves or the owner of the network. Eg., home computers implement stub resolvers talking to the nameserver included in the home router, which does the DNSSEC. You have to trust the server the stub resolvers are talking to, but that server's the little box sitting on the shelf above your computer instead of some random nameserver several hops out under the control of someone you don't know. Or you're at a company and you're trusting the nameservers the company runs for their network.

The only place it breaks down is when you're attached to an untrusted, public network (eg. the wireless hotspot at the local coffee shop), at which point you want additional precautions anyway because that kind of network could be using IP routing to funnel all your traffic through a malicious server even if you're getting the correct IP addresses from DNS.

Re:Optimistic guy (1, Insightful)

Anonymous Coward | more than 4 years ago | (#28467049)

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

I guess it depends if you care about getting the correct IP address back when resolving a host or not.

Personally, when i type google.com into a resolver, I kinda like to get one of the IPs google wants returned for it, and not an IP the ISP or a hacker wants returned for it.

To each their own thou!

Re:Optimistic guy (1)

TheRaven64 (641858) | more than 4 years ago | (#28467537)

Personally, when i type google.com into a resolver, I kinda like to get one of the IPs google wants returned for it, and not an IP the ISP or a hacker wants returned for it.

See, it's boring people like you who take the fun out of web surfing. Down with DNSSEC!

Re:Optimistic guy (1)

jafiwam (310805) | more than 4 years ago | (#28469189)

Hey, if there is enthusiasm, there must be a good idea!

Just look at Mr. Moller and his wonderful new car!

Plenty of Boring Topics on Slashdot (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#28466763)

Has anyone noticed the recent increase in the number of shockingly boring topics on Slashdot?

Need DNSSEC tools (2, Interesting)

snsh (968808) | more than 4 years ago | (#28467089)

I haven't deployed DNSSEC yet on my external domains because of cost/complexity. When I looked into it, my options for DNSSEC were:

1) implement BIND and do the key management and rotation from the command line
2) spend $10,000 or so for an appliance from secure64 or nixu
3) spend $1k/month for a hosted DNS provider like neustar or verisign
4) install Win2008R2 RC and use it in producition

I work in a windows shop, so I'll probably go with option 4, but I'm surprised there aren't more set-it-and-forget-it tools out there for DNSSEC deployment. I'm open to recommendations.

Re:Need DNSSEC tools (4, Informative)

Effugas (2378) | more than 4 years ago | (#28467207)

(this is dan)

Yeah. This is being worked on. By the time the root is signed, you should have much more at your disposal.

Re:Need DNSSEC tools (0)

Anonymous Coward | more than 4 years ago | (#28470725)

In response to your post about implementing DNSSEC, there are other, less expensive options for a DNSSEC enabled managed DNS service. One of them is Dynect Platform, who just announced support for DNSSEC last week: http://dynamicnetworkservices.com/news-press/DynIncPushesDNSSECLiveandDrivesAdoption

Depending on your needs, you're talking about $100s of dollars a month, not $1000s.

Questions from a DNS implementor (4, Interesting)

Ex-Linux-Fanboy (1311235) | more than 4 years ago | (#28467417)

OK, since Mr. Kaminsky is following this thread, I figured this would be a good place to open up some questions and a discussion between a DNS implementor and Mr. Kaminsky.

Let me introduce myself: My name is Sam Trenholme and I am the implementor of MaraDNS [maradns.org], a recursive and caching DNS server. Right now, I am in the slow process of re-writing the recursive DNS resolver [blogspot.com]. While MaraDNS has always been as secure as non-DNSSEC can be against Mr. Kaminsky's bug [blogspot.com] (DJB knew about the problem back in 1999 and I implemented his solution to randomize both the query ID and the source port back in 2001), I am wondering:

How hard is it to implement DNSSEC in my recursive cache? How many RFCs am I going to have to toil over to understand DNSSEC well enough to implement it? About how long will it take me to code MaraDNS to have full DNSSEC support?

I have a bad feeling that DNSSEC is a monster to implement and that we will not see many independent implementations of it; right now BIND and Unbound appear to be the only DNS servers to support it. DjbDNS doesn't support it, of course, and probably never will. My own MaraDNS and PowerDNS also don't support.

What are your thoughts? Has a reasonable effort been made to make DNSSEC easy to implement?

Re:Questions from a DNS implementor (0, Flamebait)

BitZtream (692029) | more than 4 years ago | (#28468089)

Considering you can't be bothered to read the information out there to even understand it, I think you'll find it very hard.

Its not actually hard if you use someone elses encryption libraries, but if you are too lazy to even lookup how it works, and its fairly clear you have no understanding of how it works, its probably safe to say you are going to consider it hard.

In reality, its not really a any worse than say adding SSL support to a web browser.

Re:Questions from a DNS implementor (1)

foom (29095) | more than 4 years ago | (#28468515)

36 RFCs [dnssec.net] over the course of 12 years for a not-even-deployed-yet standard really is quite excessive. I don't blame him for thinking it's going to be a monster...

Re:Questions from a DNS implementor (1)

Ex-Linux-Fanboy (1311235) | more than 4 years ago | (#28468533)

And, since you're too lazy to post links to DNSSEC howtos (like this one [dnssec.net]), you're not helping and only name calling. The issue is that there are 15 RFCs with DNSSEC in the title [rfc-editor.org] and no clear idea where to get started.

But, hey, this is Slashdot, where any idiot can get a lame name like "BitZream", and post insult anonymously.

No worries; I will email Dan and talk to him offline about it.

Re:Questions from a DNS implementor (2, Interesting)

Effugas (2378) | more than 4 years ago | (#28468185)

(This is Dan)

Heh Sam,

      It's a bit tricky, but we can work with you on the trickiness. DNSSEC is *much* easier to implement if you drop the somewhat unnecessary requirement for offline key signing, which is why BIND is so messy. Libunbound/ldns is flexible enough so you can integrate it, otherwise we can help you with the various wonkiness. Email me offline, dan@doxpara.com ?

Re:Questions from a DNS implementor (1)

Ex-Linux-Fanboy (1311235) | more than 4 years ago | (#28468679)

Hey, Dan, I just sent you an email offline from my gmail account. If you didn't get the email (if it somehow got eaten by a spam filter or what not), post a follow-up here. Thanks!

Re:Questions from a DNS implementor (1)

Anonymous Coward | more than 4 years ago | (#28468923)

I was very pleased to see this discussion taking place in an open forum, and would loved to have had the opportunity to follow it. I regret you've taken your interaction offline.

I myself have been a DNS administrator (among other things) since the original implementation. I remember converting from host tables wasn't particularly fun at the time.

Re:Questions from a DNS implementor (2, Interesting)

Ex-Linux-Fanboy (1311235) | more than 4 years ago | (#28469083)

I'll post a summary of the discussion to my blog [blogspot.com]. I welcome open discussion, but I feel more comfortable posting to a place where I can filter out the trolls.

Wow, an acronym explained (1)

hey (83763) | more than 4 years ago | (#28467549)

Wow an acronym explained was explained in a slashdot story posting... "DNSSEC (DNS Security Extensions)". Oh, the DNS part wasn't :)
Yeah, I know its a very common acronym.

Is DNSSec really needed? (1)

mr exploiter (1452969) | more than 4 years ago | (#28467557)

The kaminsky attack is an attack on a client that is dumb enough to allow to make thousands of dns requests to subdomains of a domain. If the solution is changing to DNSSEC the clients will have to change to DNSSEC too, so we may as well prevent the attack by making the DNS clients smarter. For example a rule could be added that says that if there were more than 10 invalid responses for subdomains of the same domain then when a valid response arrives only to cache the IP for the subdomain requested and not for additional domain names included on the response.

Re:Is DNSSec really needed? (3, Informative)

Effugas (2378) | more than 4 years ago | (#28467739)

(This is Dan)

Too many exceptions, like www.facebook.com's low TTL, or CNN's non-response to nonexistent names, etc.

Re:Is DNSSec really needed? (1)

Sancho (17056) | more than 4 years ago | (#28468029)

It's a matter of the scope of the attack. Any resolver (including your ISP's caching nameserver) can be the target. It wouldn't make much sense for an individual's resolver (their PC) to be the target--first of all, it's hard to get them to query for thousands of requests. Second, your payoff is small--you got one machine to think that ns1.example.com resolves to your IP address.

The real target is any caching server that lots of people use. It's much easier to get these to make requests for lots of subdomains (nslookup aaaaaaa1.example.com; nslookup aaaaaaa2.example.com, etc.) And once you've compromised it, you've compromised the DNS for everyone using that server.

Implementing DNSSEC on the caching resolver fixes the wide-scale attack without ever having to touch the clients. Now, an attacker can only target individual PCs. It's an issue, but a much smaller one. For one thing, you don't compromise a million people by attacking one host anymore. You have to do it individually, which makes it much less attractive. For another, it's harder to get into a position to target that user, as you have to get their computer to make the queries. If you can do that, you probably have access to their computer and can make simpler attacks (such as modifying the hosts file.)

key point: DNSSEC enables NON-dns security stuff (0)

Anonymous Coward | more than 4 years ago | (#28472071)

The slashdot discussion is focussing on the implications for DNS itself, when DNS is the least interesting benefit from DNSSEC.

Kaminsky, FTA:

[...]I don't think people fully realize DNSSEC is not interesting because of DNS. The lack of DNSSEC is why all these other protocols are broken. That 60% of attacks that happen because of poor authentication -- do you know why authentication was poor? Because it was too expensive do anything better. DNSSEC will enable better authentication technologies; stuff we can't even dream about yet.

Question for Dan: signing the root (1, Interesting)

Anonymous Coward | more than 4 years ago | (#28467991)

Hi Dan,

Stupid question: can whoever holds the root key forge requests from all domains?

e.g. if I am the US government, can I spoof an .ir domain?

Thanks.

Re:Question for Dan: signing the root (0)

Anonymous Coward | more than 4 years ago | (#28471723)

Mod parent up!

Re:Question for Dan: signing the root (1)

deananderson (258701) | more than 4 years ago | (#28473009)

Yes. But the us govt could do that before. DNSSEC doesn't enable this.

DNSSEC only enables a false sense of security that it wouldn't happen, while leaving the man-in-the-middle attack ignored and vulnerable.

There are basically two kinds of attacks: Man-in-the-middle (MITM) and blind attack which cannot see responses. UDP Port randomization makes blind attacks quite nearly impossible, and this has been known since 1999 or before. TCP DNS makes blind attacks impossible.

If the attacker is in the middle, it does not matter what DNS does, because the attacker can intercept the packets to the "right" IP address returned by DNS. So to protect against MITM attacks, one MUST use TLS or similar, and one MUST check that the correct certificates are returned. Nothing else will suffice, so DNSSEC is useless and solves no problem.

Re:Question for Dan: signing the root (0)

Anonymous Coward | more than 4 years ago | (#28474477)

why would there be only one root? key management would be a serious issue, but i doubt that the any government would be given sole control of the root key.
1) an NGO such as ICANN/ISV/etc
2) per domain tld root keys with com/net/org being NGO controlled (even if its something US based)

Will DNSSEC my ISP's dns hijacking? (1, Interesting)

Anonymous Coward | more than 4 years ago | (#28468011)

I've got verizon and when I look up non-existent TLDs I get back a records of 8.15.7.117, 63.251.179.13, and 67.63.55.15.

Now, maybe that would be cool if I were using their DNS servers but I'm using dnscache running on localhost, so they're hijacking requests to root servers.

So, WTF, and will DNSSEC make any difference in this?

I don't wanna put a subject. (1)

FunkyELF (609131) | more than 4 years ago | (#28468307)

I was actually thinking about this the other day.
Http has absolutely no security at all built into the protocol. It is all hacked together with cookies and the server remembering sessions etc.
The protocol itself is dumb. Make a request... get a response, thats it. Any security is on top of that.
If there was a standard for secure HTTP, all of these gimmicks and schemes could be removed from the hundreds of web frameworks and implemented in the browser / http server.

Re:I don't wanna put a subject. (0)

Anonymous Coward | more than 4 years ago | (#28468487)

>If there was a standard for secure HTTP

Yeah... if only there was a way to wrap HTTP in something like SSL..... that would be too easy though.

Re:I don't wanna put a subject. (2, Interesting)

Todd Knarr (15451) | more than 4 years ago | (#28468615)

There already is a standard: SSL. It includes encryption (to secure the content going across the channel against eavesdropping) along with bidirectional authentication (server certificates to verify that you're talking to the server you think you're talking to, as well as the less-commonly-used client certificates to authenticate to the server that you're who you claim to be).

If I were setting up a secure site, it'd be SSL-only. As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account. From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username. And I've long suggested that, for user security, browsers have a feature where the user can associate server certificates with identities and then, by selecting an identity to communicate with, limit the browser to accepting only servers presenting one of the certificates associated with that identity. Have a way for the user to download the server certificate as part of the account setup process and you pretty much eliminate the need for PKI to support the whole thing, self-signed certificates will work since they were gotten directly from the source. You still need verification of both ends, but it's limited to just during the account setup process and isn't an ongoing thing.

Re:I don't wanna put a subject. (1)

atomic-penguin (100835) | more than 4 years ago | (#28468837)

That isn't what the original poster meant by security. Encryption only secures the transport, that does not mean SSL and TLS secures HTTPS from any exploits.

Re:I don't wanna put a subject. (1)

Todd Knarr (15451) | more than 4 years ago | (#28469063)

Well, SSL/TLS can, with the proper use of certificates, secure the endpoints against impersonation attacks. If, for instance, the browser has the server's certificate directly in it and won't accept any others, then it doesn't matter if the attacker can redirect the traffic to their server and forge DNS perfectly, the browser will still reject the server because it doesn't have the certificate the browser expects. Ditto the other way using client certificates. An attacker would have to compromise the endpoint itself and gain access to it's private keys to compromise the communication. You still do have to protect the server against things like buffer-overflow attacks on the software it's running, but that's sort of a given regardless of what else you use.

SSL/TLS won't, of course, protect a client against malicious content sent by a valid server. But then it's not intended to. It protects the communications channel, it doesn't make guarantees about what the endpoints will send across that channel.

Re:I don't wanna put a subject. (1)

Lennie (16154) | more than 4 years ago | (#28469011)

This is actually one of the things I'd love to see if DNSSEC actually does get going for real.

I'll love to be able to put SSH pub-keys and SSL(https) pub-keys in a verifiable DNS.

At this point tooling, etc. really needs to be improved if I'm going to implement DNSSEC on my domains.

The whole key-rollover stuff is still to complicated.

Re:I don't wanna put a subject. (1)

rho (6063) | more than 4 years ago | (#28471111)

If I were setting up a secure site, it'd be SSL-only. As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account. From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username.

Your suggestion just gave me the piss-shudders.

A lot of people are incapable of correctly setting up Outlook. You will build the worlds most secure site that nobody uses.

Re:I don't wanna put a subject. (1)

Todd Knarr (15451) | more than 4 years ago | (#28471565)

Why should it be hard? We're not talking about getting a CA-signed certificate verifying identity here, it's a self-signed certificate to insure that only the person who created the account accesses it. Prompt for a couple of things like name, generate and sign and add to the appropriate certificate stores for use. Assuming you're not just reusing a certificate you've already generated. This should be trivial, it's just that the toolmakers (browser makers, etc.) don't bother with proper support for more than the bare basics of SSL.

Re:I don't wanna put a subject. (1)

rho (6063) | more than 4 years ago | (#28472713)

Why should it be hard?

And then:

This should be trivial, it's just that the toolmakers (browser makers, etc.) don't bother with proper support for more than the bare basics of SSL.

I think you answered yourself.

The Web works because it has very low friction. Having to play idiot games with certificates and managing them adds tremendous friction. That you don't seem to see this suggests you haven't thought very carefully about the consequences of such a system, if at all.

The reason why DNSSEC seems to be such a good idea is because it gets you a high percentage of exactly what you're talking about without being an utter UI cockup.

Re:I don't wanna put a subject. (1)

Todd Knarr (15451) | more than 4 years ago | (#28472849)

That's the thing, though: it shouldn't need to add significant friction. There's no games to play, and minimal management that ought to be needed. It should be about as complicated as keeping track of the credit cards in your wallet, which seems to be well within the realm of the majority.

Actually UI is a real problem for DNSSEC (1)

billstewart (78916) | more than 4 years ago | (#28475693)

Some parts of the DNSSEC process invite clean UI connections - setting the keys, running human-oriented query tool, etc. It's far easier if you include registering the key as part of the process of registering the name, of course. But that's not how most people use DNS.

So you type a URL into your browser, and the browser hands it to a a resolver client, and the resolver client does a query. With Vanilla DNS, if the query fails, the client tells the browser it fails, and the browser either gives you some "can't find bad.example.com" message, or all too commonly hands your query off to a search engine which gives you a page of "Bad Examples For Sale!!" With DNSSEC, there's another possibility which your browser designer had not considered, and which your DNS client may or may not have considered, which is that it gets a DNS response back, but the response's signature is bad, or the response doesn't have a signature even though it should. What does the client tell the browser, and what does the browser tell the user? And does the user have a bloody clue what to do about it?

Another popular misbehaviour today is that the DNS server your resolver client talked to couldn't find the domain, so _it_ gave you the IP address of an HTTP server that responds to URL requests with queries for Bad Examples. This is an annoying behaviour if you're using a browser, but it's much more annoying if you weren't doing HTTP at all - you were trying to send email or telnet/ssh or connect to an IRC server or doing HTTPS on Port 443 or doing HTTP but on Port 8080, etc., and in most of those cases the DNS service's http server doesn't have those other services. Also, you might have been checking the IP address because you got mail from random-junk-dadfsadfdsaf.com, and your mail handler is trying to find out whether it exists (if not, it's guaranteed to be spam.) Will DNSSEC force ISPs to stop using that kind of DNS service/server? Or will you get even more incomprehensible responses, like a bad DNSSEC signature on the original query getting replaced by a valid signature on a DNS response from misbehaving-DNS-service.com's http server?

Re:I don't wanna put a subject. -OK, house analogy (1, Insightful)

Anonymous Coward | more than 4 years ago | (#28468751)

That's kind of the point. Dan has found a flaw in the basement of your house.
The entire house is in jeopardy, no matter how well built. Every house affected.

Do you :
A: Call Kaminsky a damn liar, denounce his snake oil, sip your turpentine.
B: Stucco and paint every 10 days, whistling to yourself forcefully.
C: Try to jackhammer out the flaw and form up some new foundation meantime
D: Nuke the house from orbit, start from scratch, total web tech re-over in IPv6

I think Dan proposes C and eventually D. Most people stuck on A and B.

But hey, when the internet fails, just think of all the free time you'll have.

Dumb Question (2, Insightful)

John Hasler (414242) | more than 4 years ago | (#28468761)

But since I don't claim to understand DNSSEC I'll ask it: how secure is DNSSEC against abuse by governments?

Somewhat secure - everything's in the open (1)

billstewart (78916) | more than 4 years ago | (#28475817)

Nothing's perfect, but the DNSSEC signature process is mostly out in the open - you can see the public keys for the name servers, and you can check the signatures on the keys for yourself, and you can also get yourself domain names almost anywhere in the world if you don't like a given registrar/registry. So while a government _could_ probably bully a registry into signing a forged certificate for your domain name, it would at least be publicly visible that "your" key had changed.

Also, the government foot-dragging that's delayed DNSSEC deployment and root/com signing for so many years has led to the development of "Trust Anchors", which are a mechanism for getting DNSSEC keys and validation independent of the upper DNS hierarchy, and they provide an extra mechanism for verifying keys.

KillerNapalm (0)

Anonymous Coward | more than 4 years ago | (#28470693)

Security is a process... not necessarily a product or a deployment of a new technology.

DNSSEC has the ability help, but its no substitute for proper design, management, and the continuing upgrade/improvement roadmap thereto. Anything and everything eventually is found to have weaknesses. True security is the ability to stay at least one step ahead of the bad guys.

Kaminsky/Vixie DNS Scam Known as Media Hack (1)

deananderson (258701) | more than 4 years ago | (#28472855)

I think my comments to the NTIA on DNSSEC hit the point on Kaminsky and the DNS scam. As others pointed out, this is a group of shysters. MIT's "Technology Review" picked up the "Media Hack" aspect of the Story in December. That article is a good read if someone has a link.

Here are my NTIA comments which detail the Kaminsky/Vixie scam aspects and expose problems with DNSSEC:
http://www.ntia.doc.gov/dns/comments/comment027.pdf [doc.gov]

One of the things not detailed in my NTIA comments is that Kaminsky tells people to move to OpenDNS.ORG, run by Vixie associates David Ulevitch and Bill Fumerola. Fumerola is also a friend of Chris Neill. IADL has a page on Neill and his connection to spam-abuse at
http://www.iadl.org/cn/cn-story.html [iadl.org]

On .ORG Signing

While the .ORG TLD was indeed recently signed, I could not get .ORG TLD officials to respond to questions about whether there was regulatory approval for their actions. It is also telling that Vixie is involved with .ORG TLD. The .ORG signing appears to be an effort at "persuasion"--Sort of 'See, we did it'. But as my NTIA comments spell out, there are two serious DDoS attacks created by DNSSEC. While one perhaps might block .ORG servers during an attack, one cannot block the root DNS servers.

Google "dean anderson" troll Vixie for more info (0)

Anonymous Coward | more than 4 years ago | (#28475741)

I occasionally see posts by Dean Anderson at av8.net on the North American Network Operators' Group (NANOG) - almost always obsessive flames about Paul Vixie.

I'm not sure if this post fails the "Don't feed the trolls" test or not, but it sort of needs to be said.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...