[tptacek]

Google, with its plentiful expertise and cash, counts as its two fiercest competitors two of the three organizations that would need to agree with any new solution to revocation.

Meanwhile, you've offered a "sketch of a solution" that involves CAs (a) cooperating with Google and (b) employing computer science in the pursuit of writing actual code. Why not talk to Comodo and see how likely that is to happen?

You know who thinks CRLsets suck? Adam Langley. Certificate revocation is broken. They did what they could. Google didn't design SSL revocation.

All Google has done is orchestrate the adoption of TLS forward secrecy, fixed security vulnerabilities (for many years running) in OpenSSL (along with virtually every other component to modern web browsers, along with ffmpeg and the open source video stack), invented and deployed browser certificate pinning, spearheaded the deployment of Certificate Transparency, oh, and found/fixed Heartbleed.

But, I'm sure your comments are great. Why not take them to the IETF TLS WG? I'm sure you'll find an eager audience. I am not kidding.

[gojomo]

Cooperation of competitors is not necessary — that's an excuse for inaction. As with 'Safe Browsing' (or CRLSet), one browser could lead the way, letting the others follow the same model or improve later.

Similarly, CA buy-in is not a blocking prerequisite for a better approach — it's just another excuse for inaction. Exactly as with CRLSet, the browser vendor can say, "we'll scrape your revocations where we can find them, or you can provide them this way". Then, if an incompetent or recalcitrant CA hides their revocations, it's an issue between the CA and their harmed customers.

It's great you, me, and Adam Langley all agree that revocation is broken, including Google's stopgap proprietary solution. But hasn't everyone understood that for 15+ years? Why isn't there a fix?

The browser makers absolutely own responsibility for this, because they're the ones that show end-users a security indicator. They're shipping the software that creates a risk, they can unilaterally fix this on their own initiative, and they're not so poor or stupid that fixing it should be beyond their capabilities.

Yes, Google has done a lot for security. Their 'web security karma' is very net-positive. They still deserve a demerit, along with Mozilla and Microsoft, on this particular issue.

Referring this to the IETF for standardization is just another way of excusing more inaction and delay.

[tptacek]

Why are TLS block cipher constructions still MAC-then-encrypt, 13 years after Bellare and Namprempre proved that was the wrong way to do it? Because standards are hard.

You can blame the browser makers as much as you want, but among them as a group, nobody has worked harder on making TLS better and safer than Google. But here you are berating them for the effort.

[einhverfr]

But the objection is still the same.

Here's the thing. I have been advertising the impact of this decision by Chrome on our SaaS business. It just isn't acceptable that cert revocation means one thing if you are Yahoo but another if you are a startup SaaS business.

As I have said repeatedly, this is a way to ensure that things are comfortable enough for the people at the top that everyone else is sacrificed in the name of it being too much trouble, working for free, etc. But as long as the big sites are protected by Google, nothing will get fixed and us smaller competitors will be screwed.

I am sorry, but that's just morally wrong. And it is the major reason I now recommend Firefox over Chrome.

[gojomo]

Again, standards don't need to be a blocker for the revocation issue (as CRLSet itself demonstrates). "Standards are hard" is an excuse for inaction.

I can applaud Google's efforts in general yet still point out when there's one egregious, embarrassing gap. They are one of the only three institutions worldwide that could possibly fix this for users, and I'm not picking on them over the others.