SSL and CAs
The CA model of SSL has always bothered me. The idea of a trusted third party feels eerily close to maffia security: you believe this person, whom you don't know, is who he claims he is on nothing more than the word of this other person, whom you also don't know.
The DigiNotar story proves how problematic this model is, but you don't really need that to understand its problems.
For the longest time, however, there simply was no better way to properly do these things. But now that we have DNSSEC, do we really still need CAs? Really? Can't we just store a fingerprint of a per-domain signing key in the forward (and, possibly, reverse) DNS zone of the host in question, have that signed by DNSSEC, and have the browser check the full DNS chain of the zones in question in addition to the signature on the certificate instead?
I'm sure the CA business people would hate to see that happening, but really, paying someone so they say whatever you tell them to say? Try that in court, and they'd lock you up.
Update: It's called the DANE protocol. No, that has nothing to do with Denmark: DANE stands for "DNS-based Authentication of Named Entities".
No, DNSSEC does not help the SSL CA situation at all. What kind of SSL key do you install in your DNS setup? Doesn't it need to be signed by someone to be trusted? Who is that? Turns out the idea of using DNSSEC is even worse that than the SSL CA situation.
48-minute video from Moxie Marlinspike on the subject (starts off as entertaining):
https://www.youtube.com/watch?v=Z7Wl2FW2TcA
More detail if you don't have 48 minutes:
http://nakedsecurity.sophos.com/2011/08/16/defcon-2011-ssl-and-the-future-of-authenticity/
DNSSEC may be able to ensure that data from DNS servers is not tampered, but it does not protect communication from eavesdropping or modification. (you can apply any man-in-the-middle attack to regular IP packets regardless of whether the peer's IP address was resolved via DNSSEC or non-secured DNS)
And for DNSSEC you still need trust. In fact, you need a chain of trust that goes from a trust anchor (such as ".") to the domain you're resolving, such as www.example.co.uk. Do you really trust ".", "uk.", and "co.uk."? Can you trust any of the later names just because you trust the root name?
I think the answer has to be "no", because while certificate issuers at least in principle understand that they are dealing with security issues (and therefore will give at least some thought to threats against their organization—particularly if it's clear that a discovered illegitimate certificate is a death sentence for the organization), domain name registrars historically know no such thing, and they'll be slow to learn it.
Wouldn't DNSSEC only help with making sure the domain name is correct? E.G. that you really did get to examplebank.com so it matches the website to the domain.
It doesn't help with matching the server to the organisation, that examplebank.com is really owned by Example Banking Co.
Still, its better than nothing. I'd be curious to see how DNSSEC goes and of course what evil corner-cases there will be in the real world. (nothing is perfect)
I fear you are confused about the object of trust here. The information being trusted is solely ownership, which, in fact, the domain registrar is the only entity qualified to certify.
Questions of the trustworthiness of the owner is an entirely separate question which is not, or is only dealt with by smoke and mirrors, by current certification systems.
So it all boils down to the question if you can trust your "upstream" TLD. Previously you already placed trust in them delivering the right set of nameservers to those who ask about your domain.
However, if they were hacked and delivered the wrong ones and also wrong A/AAAA records below your domain, you've got a man-in-the-middle situation. SSL had some (FSVO some) out of band checks that you're talking to the right person.
So now they can easily put in new keys for your domain (because they control the trust delegation) and forge a signed zone. As you're placing all your trust into this, and as you won't pin the public keys like you don't pin them today, you just moved the problem to a different entity.
Yes, this really might not be worse than the current situation, but I'm not sure it's entirely great neither. (Although I'd applaud getting rid of the CA model.)
Have you checked out the Carnegie Mellon University developed Perspectives Project? They have a Firefox plugin: http://perspectives-project.org/
Press release here: http://lwn.net/Articles/295358/
and for Chromium: http://perspectives-project.org/2011/07/08/perproxy-ubuntu-chrome/
With DNSSEC, from what I understand, you just move the trust issue to other entities.
There's an alternative solution called Convergence which tries to solve the issue by not caring about CAs and implementing other distributed methods to verify the correctness of the certificate. Here's a blog post of the author: SSL And The Future Of Authenticity. You can watch his entertaining and enlightening presentation of the system here:
Balau.
"Convergence is based on the ideas originally developed by the Perspectives Project at Carnegie Mellon University."
I tried the Convergence firefox plugin, but it didn't work well for me so I switched to the Perspectives firefox plugin.