The migration away from the CA model is called "certificate pinning". Chrome uses it for high-value sites, and you use it whenever you ssh somewhere and the key's fingerprint is in your .ssh/known_hosts file.
>The migration away from the CA model is called "certificate pinning".
TOFU/POP is not an effective model for the web. There are simply too many sites for it to be useful. It's pretty much an everyday occurrence that I go to a site I've never been to before, and certificate pinning won't help at all there.
First, "TOFU/POP" has a real name; it's "key continuity". Second, certificate pinning as implemented in Chrome doesn't depend directly on key continuity. Third, key continuity destroys the incentive to attack sites by compromising CAs, because even if you're hitting a site for the first time, many of the 10,000 other people hitting it from the same browser at around the same time aren't, and they'll detect the bogus cert. That only has to happen once for Google to put a gun to the rogue CA's temple.
Well, what Google does is it gets a list of revoked certs from CA's, decides which ones are "really important" and sends those to the browser. So yes, in effect, Google decides which certificates are revoked. It's all covered in the article.
No. You're not following me. You think I'm describing agl's point. I'm not. I'm saying that beyond CRLsets, certificate pins also allow Google to detect misbehaving CAs. CAs have power only to the extent that Google allows them to have power by keeping them in Chrome's root CA key store. Google can pick among most of the current CA's and put them out of business on a whim.
> certificate pinning as implemented in Chrome doesn't depend directly on key continuity.
But it's unsuitable for the entirety of the web. You can't hardcode all certificate fingerprints of the whole internet inside the browser.
>> The migration away from the CA model is called "certificate pinning".
> key continuity destroys the incentive to attack sites by compromising CAs
We need to ELIMINATE CAs (CA as in some third party (google, Verysign, GoDaddy, ...) who you have to trust). The whole concept of trusting a CA is broken, and pinning does nothing to address that, at least not in the proposed TACK implementation.
Yes, but TACK, even if it's a big step forward, does not address the main problem: we need to get rid of a central authority we have to trust. And TACK does nothing to address that. And neither does Certificate Transparency as proposed by Google.
I really feel the correct step forward is Convergence or Perspectives. If just browser vendors would jump in, we could use it right away. Mozilla/Google could set up a few notaries and set them as trusted by default in the browser. They choose the CAs they put in our browsers anyway, so we trust them already. That trust could be implemented with notaries instead of the CA model, so if someone wants to setup their own notaries they can.
What's your take on this? I value your opinion on security matters.
By moving towards decoupling the CAs from the Internet trust model, TACK is a step towards getting something like Convergence bootstrapped. Once we accept that the CAs are a utility player and not the ultimate arbiter of security, it's not hard to get to a place where we can start verifying "pins" with sites run by EFF or ACLU.
The biggest security problem on the Internet isn't protocols and it isn't cryptography. It's that the UX the browsers have for managing/configuring Internet trust hasn't changed since the late 1990s, and it's buried 3-4 levels deep in the "no user serviceable parts" section of the config UI. There are a lot of very productive things you could do for Internet security simply by revamping that UX, without making a single wire-level change to the TLS or HTTP protocols.
