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.
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.
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.
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.
What FX has shown is that each hardware line tends to have enough in common that exploits can be built independent of the individual version of software deployed on that piece of hardware. That's a decrease in variability of at least a couple orders of magnitude.
!exploitable isn't about finding bugs -- it's not a fuzzer, it's not a static analyzer, etc. It's about looking at a crash and saying, "Heh, this isn't just a Null Pointer Deref, you got EIP." Sure, that's obviously exploitable to you, but to some junior tester, that's not obvious at all.
That's why it's a game changer. The dev writing the buggy code can't just say, meh, prove it's exploitable. Now the tester can point out the output of !exploitable and say, prove Microsoft is wrong. Shifts the burden of proof in the exact direction you'd want.
This is true historically. However, I (this is Dan Kaminsky) think it's a mistake now. DNSSEC needs to be pushed into the nameserver's automated functionality about as deeply as possible. Administrators simply cannot be asked to maintain this data, manually resigning zones, manually keeping keys from expiring. It doesn't scale.
Don't worship DJB too closely. Remember the birthday attacks from 2002? DJBDNS only got patched against them a week or two ago...not even after I pointed out that their protection was missing, but after Kevin Day went ahead and built an exploit against it.
Well, for one thing, 1.www.google.com has access to the www.google.com cookie. It's also a really good place to phish from. In some circumstances, document.domain is even set up such that 1.www.google.com has script level access to www.google.com. Not good.
At this point, BIND, Nominum, Unbound, and Microsoft all suppress colliding queries. The only name server I know of that doesn't is DJBDNS, and it drops its security level noticeably.
Green bar is a great marketing ploy, but it really should be an httpsev:// URL handler if we wanted it to be secure. Collin Jackson's done some really good work around this, go google him.
Glue distrust isn't that big of a deal. It's sufficiently damaging to the browser security model just to inject arbitrary subdomains into extant domains.
And, no offense to DJB, but port randomization is not by itself a sufficient response to the birthday attack. Come on, we've known not to have simultaneous outstanding requests for the same name for the last six years.
Regarding EV, https://www.yourbank.com (EV cert) == https://www.yourbank.com (domain validated cert) -- as far as the browser's Same Origin Policy is concerned. So the attacker passes through enough EV for the bar to turn green, then switches over to DV for JS to come in. Not good.
The idea was that you'd target individual ISP or Enterprise name servers, which would be trivially reachable via a simple ad network. You'd hit com, then use basic caching to grab what you liked.
I took a look at what Rogers is doing. They're using PaxFire, who indeed was directly vulnerable to the attacks I described at Toorcon a few months ago. PaxFire fixed their stuff up, but yes, the security of the web at Rogers is limited to the security of those ad servers at PaxFire.
Slashdot Mirror
(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.
(this is dan)
Yeah. This is being worked on. By the time the root is signed, you should have much more at your disposal.
(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.
(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.
(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.
I actually worked with the researchers on this. (This is Dan.)
What FX has shown is that each hardware line tends to have enough in common that exploits can be built independent of the individual version of software deployed on that piece of hardware. That's a decrease in variability of at least a couple orders of magnitude.
This is Dan.
OK, my DNS bug took two days to find, and six months to fix. I'm not sure what universe you're in; in mine, we have to actually test.
Sup Goth, this *is* Dan.
!exploitable isn't about finding bugs -- it's not a fuzzer, it's not a static analyzer, etc. It's about looking at a crash and saying, "Heh, this isn't just a Null Pointer Deref, you got EIP." Sure, that's obviously exploitable to you, but to some junior tester, that's not obvious at all.
That's why it's a game changer. The dev writing the buggy code can't just say, meh, prove it's exploitable. Now the tester can point out the output of !exploitable and say, prove Microsoft is wrong. Shifts the burden of proof in the exact direction you'd want.
This is true historically. However, I (this is Dan Kaminsky) think it's a mistake now. DNSSEC needs to be pushed into the nameserver's automated functionality about as deeply as possible. Administrators simply cannot be asked to maintain this data, manually resigning zones, manually keeping keys from expiring. It doesn't scale.
Don't worship DJB too closely. Remember the birthday attacks from 2002? DJBDNS only got patched against them a week or two ago...not even after I pointed out that their protection was missing, but after Kevin Day went ahead and built an exploit against it.
Well, for one thing, 1.www.google.com has access to the www.google.com cookie. It's also a really good place to phish from. In some circumstances, document.domain is even set up such that 1.www.google.com has script level access to www.google.com. Not good.
At this point, BIND, Nominum, Unbound, and Microsoft all suppress colliding queries. The only name server I know of that doesn't is DJBDNS, and it drops its security level noticeably.
It's everyone with an EV cert.
Green bar is a great marketing ploy, but it really should be an httpsev:// URL handler if we wanted it to be secure. Collin Jackson's done some really good work around this, go google him.
Technically, everything in Paketto comes from a rather evil reading of TCP RFC's :)
Since the non-green-bar site has Javascript access to the green-bar site, the green bar doesn't actually mean anything.
See http://www.doxpara.com/DMK_Neut_toor.ppt to see why this is still a problem.
Oh come on, ARP cache poisoning is trivial :) There's also a good dozen ways on LAN to hijack all traffic, so you're never fixing that.
Glue distrust isn't that big of a deal. It's sufficiently damaging to the browser security model just to inject arbitrary subdomains into extant domains.
And, no offense to DJB, but port randomization is not by itself a sufficient response to the birthday attack. Come on, we've known not to have simultaneous outstanding requests for the same name for the last six years.
Regarding EV, https://www.yourbank.com (EV cert) == https://www.yourbank.com (domain validated cert) -- as far as the browser's Same Origin Policy is concerned. So the attacker passes through enough EV for the bar to turn green, then switches over to DV for JS to come in. Not good.
The idea was that you'd target individual ISP or Enterprise name servers, which would be trivially reachable via a simple ad network. You'd hit com, then use basic caching to grab what you liked.
This is Dan Kaminsky, finder of the bug.
No, this isn't a reasonable fix. Nice try, but no. See http://www.doxpara.com/?p=1234 for details.
(Incide
BTW, do you have a real name I can credit you by? Or should I just refer to you as Imipak?
Check out the new slaving info at www.doxpara.com. Does it work for you?
[This is Dan Kaminsky]
I took a look at what Rogers is doing. They're using PaxFire, who indeed was directly vulnerable to the attacks I described at Toorcon a few months ago. PaxFire fixed their stuff up, but yes, the security of the web at Rogers is limited to the security of those ad servers at PaxFire.
[This is Dan Kaminsky]
The NAT vendors didn't get as much notice because we didn't realize so many of them were doing this.
If we had, they'd have been brought in from the start.
Now they're scrambling, to their credit. It's a bit of a facepalm for me.
[This is Dan Kaminsky]
Er, you know you use DNS to retrieve web pages, right?
So I just watch how you retrieve my web page, and synthesize content based on the Port/TXID patterns you request my page with.
No code. Just script. And then I tell you whether you need to install a patch from your own vendor. It's not too complicated.