[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail

[Adam Langley]

On Mon, Sep 5, 2011 at 6:54 AM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> Who are the large website owners? Do they want to commit engineers to
> helping implement OCSP stapling for Firefox?

At least one of those websites would be us, and see below.

> Is there a road map for these kinds of features? Things that will stop
> patches from being accepted? Bugs that will block releases if they're
> not done, etc?

OCSP stapling support in Firefox shouldn't be too hard. I wrote the
complex bit and it's already upstream, now Chrome supports it with NSS
and a patch[1].

However, OCSP stapling may not be the answer.

OCSP stapling only allows a single OCSP response to be stapled, but
nearly everyone has an intermediate in their chain which also needs
OCSP. Assuming that we define multi-stapling, the size of an OCSP
response varies from ~500 to ~1500 bytes. Two of three of those is
serious handshake bloat.

Also, frontend servers in large deployments are often in a network
segment that cannot directly reach the outside world and which
communicate through a load balancer. On top of updating server
software to support multi-stapling and getting it out there, many
organisations would need bespoke systems for distributing the staples
to their frontend servers.

Assuming that we get all that done, it only solves the privacy problem
with OCSP and half the performance problem. We would still need a way
to make browsers insist on OCSP stapling for that site (another
HSTS-like header one supposes.)

Given that OCSP stapling has serious issues, I've looked into a Bloom
filter like structure that we would push to Chrome (see [2]) but that
ran into two problems: the number of revocations is so huge, even a
probabilistic data structure becomes problematically large. Also, OCSP
server uptime didn't seem to be sufficient, in small scale testing, to
support a hard fail, even with the filter in front.

The current idea is that we push a CRL to Chrome and eliminate online
revocation checks entirely. This solves the privacy, performance and
complexity problems. However, in order to make the CRL tractable, it
can contain only a small subset of the CRLs that we know about
(heavily weighted towards EV). If a CA wishes to be part of the Chrome
CRL then they have very limited space. (And the Chrome CRL is still
(issuer, serial number) based, given that it's made up of CRLs that
are such.)

[1] http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/patches/ocspstapling.patch?view=markup
[2] http://www.imperialviolet.org/2011/04/29/filters.html


Cheers

AGL