So, I'm posting as somebody who has gotten critical fixes pushed into both IE and Firefox. (Technically, Chrome and Opera too, but those were the pure crypto vulns.)
It's genuinely hard to write a secure web browser. Forget plugins -- you have a complex internal object model, subject to all sorts of very fine grained rules ("the filename on an input type=file form must not be settable from Javascript"), which can be made into a pile of moving parts under the control of an attacker. What's happened somewhat recently is a lot more people have gotten into bashing Firefox. You know those "many eyes" theories of open source, and how they're usually kind of full of it?
Well, "many eyes" are visiting it now, and Mozilla to their credit is doing a lot of very hard work to deal with the influx. Good on them.
It is true that DNSSEC increases aggregate bandwidth.
I'm not sure about the DNSCurve numbers right now, given that the implementation I've seen can only do about 5,000 encrypt/decrypts a second on hardware that'll do 15,000 DNS responses a second.
Yes, because browsing securely should look like UAC, with every new site throwing a prompt in your face as if you had enough information to go on.
No. We can, and need to stop imagining the user is some sort of god that can accurately judge risk of accepting unknown keys (or worse, keys 'recognizable' with some arbitrary sequence of hexadecimal characters). This is a lie we're telling ourselves, and I'm done with it.
You're right that Verisign controls.com. Guess what, they control it *today* -- they are the exclusive registrar for it. If Verisign screws up, you have accountability. When.info was filled with SPAM, Afilias (who also owns.org) cleaned it up, because they had accountability. The present system has no accountability, and so any CA -- and there's rather worse than RapidSSL out there -- has full ability to spoof everyone, in every domain. We can and should do better.
The point is that we can actually share DNSSEC responses across multiple nodes, not just a single node, using the existing framework. Yes, we will need clients that *can* go straight to the root. But they won't *have* to, which is a neat design element of DNSSEC.
Keep hitting me here though, maybe we can find a problem!
Excellent, excellent questions. This is the sort of stuff I was asking before I switched sides on the DNSSEC war.
The problem with SSL is it doesn't matter if *you* aren't paying a worthless CA; as long as a worthless CA is out there, he can corrupt every domain, everywhere. That sucks. So SSL becomes a matter of finding the least secure CA possible and compromising that.
Things are different in DNSSEC. Because of delegation, the root is the only entity with absolute power over everyone -- and the root rarely talks to anyone. Verisign is canonical for com, Afilias is canonical for org, and so on. There's no big mess of companies that can all step on eachother. There's one big mess, true, but that's it. Everything else is distributed. That is such a better situation than we have today!
Look. When some registrar had microsoft.co.nz stolen from it, it had a choice: Either clean up its act, or watch Microsoft move its registrar activity to someone that wasn't vulnerable. Microsoft had an actual response strategy. We need more systems with response strategies -- and I think DNSSEC has them.
It really is different. I can't emphasize this enough -- I wasn't a believer. Now I am.
Absolutely true. However, the ability to delegate/federate security is such a powerful force for lowering the costs of proper design and management that making this one technical change will facilitate the operational strength you correctly call out.
...not to mention that DNSCurve requires per-query crypto on the server, while DNSSEC does not (by a design that really, really wants to allow offline key signing). Curve25519 is fast but it's not *that* fast.
Estimates on cache hit rates in DNS are about 90% -- meaning for every query that hits a server, ten queries got chomped in a cache.
I'm uncomfortable asking the Internet to increase their DNS query capacity by 10x. DNS has a performance curve where once it dies, it dies kind of catastrophically. 10x increases are asking for trouble.
1) Agreed. I'm not very popular in some DNSSEC circles because of it:) But yes, the entire Trust Anchor Repository thing is a mess. That's why it's so important to get the root signed. 2) With the root signed, you always have a trusted path that says if a given domain has DNSSEC or not. If it does, stripping the DNSSEC won't matter, you'll know there's *supposed* to be signatures there. 3) Because DNSSEC delegates, it's not really amenable to the sort of tricks that have cost money in the past. If you get a.org name from Aflilias, Verisign (who is not actually evil, seriously guys) really isn't in much of a position to do anything to you on a per domain basis. The root deals with Afilias, and Afilias owns.org. It's all or nothing for screwing with things at the root. 4) See 2. 5) Not really sure what you mean here.
I don't see Verisign really being in a position to "stick it" to the states that control ccTLDs or registry's that control various gTLDs (org, info, etc). And while Verisign will in fact be able to place toll on names under com and net, they're in the competitive position of needing to be reasonable compared to org, info, and other domains. This is exactly analogous to the position Verisign has on.com and.net today, as they're the exclusive registry for those TLDs. If you don't like.com/.net policy, you don't have to use them.
Contrast with the SSL situation, where if you don't like some random SSL CA, tough, your users still trust them.
To be fair, I don't see much of a difference between NXDOMAIN and SERVFAIL except possibly impact on negative caching. Stuff doesn't work.
DNSSEC planners have been way, way too willing to let things break in order to protect non-critical features. DNS is not allowed to just return SERVFAIL. Luckily, the protocol itself is flexible enough to allow much more stable deployments.
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.
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.
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.
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.
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.
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.
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 ?
Slashdot Mirror
I think he's going to burst his eardrums, and possibly some organs.
Look. this is going to be an enormous pressure wave that will saturate his body. He pops this barrier, it's going to rattle him pretty fierce.
They really should try this with a dummy first!
They can replay it within the absolute time of the RRSIG, which can be made relatively small (needs to be long enough to handle time drift).
A web site built on flat HTML pages is more likely to be secure than a web site built on PHP. The message is the medium.
So, I'm posting as somebody who has gotten critical fixes pushed into both IE and Firefox. (Technically, Chrome and Opera too, but those were the pure crypto vulns.)
It's genuinely hard to write a secure web browser. Forget plugins -- you have a complex internal object model, subject to all sorts of very fine grained rules ("the filename on an input type=file form must not be settable from Javascript"), which can be made into a pile of moving parts under the control of an attacker. What's happened somewhat recently is a lot more people have gotten into bashing Firefox. You know those "many eyes" theories of open source, and how they're usually kind of full of it?
Well, "many eyes" are visiting it now, and Mozilla to their credit is doing a lot of very hard work to deal with the influx. Good on them.
Use the PASCO gear, with their Datastudio app. It's great, and will take all sorts of data wirelessly.
http://store.pasco.com/pascostore/showdetl.cfm?&DID=9&Product_ID=53770&Detail=1
Uh, a few machines have eight cores. Core2Duo is doing OK, but really, the heat problem is not actually going away in any way shape or form.
(This is Dan)
It is true that DNSSEC increases aggregate bandwidth.
I'm not sure about the DNSCurve numbers right now, given that the implementation I've seen can only do about 5,000 encrypt/decrypts a second on hardware that'll do 15,000 DNS responses a second.
(This is Dan)
Yes, because browsing securely should look like UAC, with every new site throwing a prompt in your face as if you had enough information to go on.
No. We can, and need to stop imagining the user is some sort of god that can accurately judge risk of accepting unknown keys (or worse, keys 'recognizable' with some arbitrary sequence of hexadecimal characters). This is a lie we're telling ourselves, and I'm done with it.
You're right that Verisign controls .com. Guess what, they control it *today* -- they are the exclusive registrar for it. If Verisign screws up, you have accountability. When .info was filled with SPAM, Afilias (who also owns .org) cleaned it up, because they had accountability. The present system has no accountability, and so any CA -- and there's rather worse than RapidSSL out there -- has full ability to spoof everyone, in every domain. We can and should do better.
(This is Dan)
The point is that we can actually share DNSSEC responses across multiple nodes, not just a single node, using the existing framework. Yes, we will need clients that *can* go straight to the root. But they won't *have* to, which is a neat design element of DNSSEC.
Keep hitting me here though, maybe we can find a problem!
(This is Dan)
Excellent, excellent questions. This is the sort of stuff I was asking before I switched sides on the DNSSEC war.
The problem with SSL is it doesn't matter if *you* aren't paying a worthless CA; as long as a worthless CA is out there, he can corrupt every domain, everywhere. That sucks. So SSL becomes a matter of finding the least secure CA possible and compromising that.
Things are different in DNSSEC. Because of delegation, the root is the only entity with absolute power over everyone -- and the root rarely talks to anyone. Verisign is canonical for com, Afilias is canonical for org, and so on. There's no big mess of companies that can all step on eachother. There's one big mess, true, but that's it. Everything else is distributed. That is such a better situation than we have today!
Look. When some registrar had microsoft.co.nz stolen from it, it had a choice: Either clean up its act, or watch Microsoft move its registrar activity to someone that wasn't vulnerable. Microsoft had an actual response strategy. We need more systems with response strategies -- and I think DNSSEC has them.
It really is different. I can't emphasize this enough -- I wasn't a believer. Now I am.
Absolutely true. However, the ability to delegate/federate security is such a powerful force for lowering the costs of proper design and management that making this one technical change will facilitate the operational strength you correctly call out.
...not to mention that DNSCurve requires per-query crypto on the server, while DNSSEC does not (by a design that really, really wants to allow offline key signing). Curve25519 is fast but it's not *that* fast.
(This is Dan)
Estimates on cache hit rates in DNS are about 90% -- meaning for every query that hits a server, ten queries got chomped in a cache.
I'm uncomfortable asking the Internet to increase their DNS query capacity by 10x. DNS has a performance curve where once it dies, it dies kind of catastrophically. 10x increases are asking for trouble.
(This is Dan)
1) Agreed. I'm not very popular in some DNSSEC circles because of it :) But yes, the entire Trust Anchor Repository thing is a mess. That's why it's so important to get the root signed. .org name from Aflilias, Verisign (who is not actually evil, seriously guys) really isn't in much of a position to do anything to you on a per domain basis. The root deals with Afilias, and Afilias owns .org. It's all or nothing for screwing with things at the root.
2) With the root signed, you always have a trusted path that says if a given domain has DNSSEC or not. If it does, stripping the DNSSEC won't matter, you'll know there's *supposed* to be signatures there.
3) Because DNSSEC delegates, it's not really amenable to the sort of tricks that have cost money in the past. If you get a
4) See 2.
5) Not really sure what you mean here.
(This is Dan)
I don't see Verisign really being in a position to "stick it" to the states that control ccTLDs or registry's that control various gTLDs (org, info, etc). And while Verisign will in fact be able to place toll on names under com and net, they're in the competitive position of needing to be reasonable compared to org, info, and other domains. This is exactly analogous to the position Verisign has on .com and .net today, as they're the exclusive registry for those TLDs. If you don't like .com/.net policy, you don't have to use them.
Contrast with the SSL situation, where if you don't like some random SSL CA, tough, your users still trust them.
(This is Dan)
To be fair, I don't see much of a difference between NXDOMAIN and SERVFAIL except possibly impact on negative caching. Stuff doesn't work.
DNSSEC planners have been way, way too willing to let things break in order to protect non-critical features. DNS is not allowed to just return SERVFAIL. Luckily, the protocol itself is flexible enough to allow much more stable deployments.
(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.
(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.
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.
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.
(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.
(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. .org is signed. .com is coming, as is the root itself. Things have changed.
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)
Standby. Seriously, this is coming, and it's not going to be miserable by the time you actually need to deploy it.
(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.
(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 ?
(This is Dan)
Too many exceptions, like www.facebook.com's low TTL, or CNN's non-response to nonexistent names, etc.
(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.