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

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.

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

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

(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.)