[tptacek]

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.

[wyager]

>First, "TOFU/POP" has a real name; it's "key continuity".

I am aware of both names, thank you.

>That only has to happen once for Google to put a gun to the rogue CA's temple.

Google can't really help in every single case. There are many situations where Google's revocation scheme can't keep up.

You also have to put a lot of trust in Google. You think Google is going to issue a revocation if they're under legal pressure not to?

As you are aware, human factors are frequently the weakest parts in a cryptosystem.

[tptacek]

I don't understand your comment. Google doesn't revoke keys. It revokes whole CAs.

[einhverfr]

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.

[tptacek]

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.

[y0ghur7_xxx]

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

[tptacek]

That's true, you can't hardcode certificate fingerprints for every site. Hence, TACK.

[y0ghur7_xxx]

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.

[tptacek]

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.