Subject: [websec] Revocation check failures for HSTS sites

From: Adam Langley <[email-masked]>
Date: Mon, 28 Mar 2011 11:36:33 -0400

Currently Chrome treats revocation check failures as fatal for HSTS
sites. This is scheduled to change with Chrome 12 when revocation
check failures will not be treated differently for HSTS sites.

The reason for this change is that several Google properties are
either already HSTS or are planning/considering enabling it. However,
it's unacceptable that a failure of our CA's servers brings down those
services. Availability of service is very important.

It has been suggested that OCSP stapling solves this issue. However,
only a single OCSP response can be stapled in the current protocol and
chained certificates are now almost ubiquitous. Even if OCSP stapling
were extended to support multiple responses, the size of the OCSP
responses (1-2KB) becomes problematic. Not only is another 2-5KB of
overhead per connection a problem for for some users (it's another
second of latency for dialups), it typically overflows the server's
initial congestion window, causing another round trip. This can be
reconfigured unilaterally on a per-server basis but many clients
enforce it with their flow window.

Cheers

AGL

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 28 Mar 2011 10:00:15 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Adam Langley
> 
> Currently Chrome treats revocation check failures as fatal for HSTS sites. This
> is scheduled to change with Chrome 12 when revocation check failures will
> not be treated differently for HSTS sites.
> 
> The reason for this change is that several Google properties are either
> already HSTS or are planning/considering enabling it. However, it's
> unacceptable that a failure of our CA's servers brings down those services.
> Availability of service is very important.

Adam,

Isn't the other option for you to get yourselves registered directly as a trusted root in the major browsers?  Won't happen overnight, but seems like it fixes the solution too if you don't have to chain to anyone to get OCSP checks, right?

- Andy

---

From: Adam Langley <[email-masked]>
Date: Mon, 28 Mar 2011 12:12:50 -0400

> Isn't the other option for you to get yourselves registered directly as a trusted root in the major browsers?  Won't happen overnight, but seems like it fixes the solution too if you don't have to…

Yes, being a root would solve our problems. Also, getting certificates
which implement revocation by having a short lifetime would work for
us. However, being a root isn't an applicable solution for others and
high-frequency certificates aren't generally available either.

Cheers

AGL

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 28 Mar 2011 10:19:18 -0600

> From: Adam Langley [mailto:[email-masked]]
> Sent: Monday, March 28, 2011 9:13 AM
> 
> Yes, being a root would solve our problems. Also, getting certificates which
> implement revocation by having a short lifetime would work for us.
> However, being a root isn't an applicable solution for others and high-
> frequency certificates aren't generally available either.

Well, you could kill two birds with one stone here couldn't you? :)

Seriously though for a second.

It seems like all of the proposed solutions on the table:

1. CAA records
2. TLSA records
3. OCSP Stapling
4. High Availability OCSP responders

All add significant  latency to connection setups, right?  All of them require another set of round trips to validate resources, pull data, etc. entirely separately from the TLS channel itself, right?

That leaves:

5. Short-lifetime certs

As the only option that doesn't require extra traffic, round-trips, etc.  Right?

- Andy

---

From: Adam Langley <[email-masked]>
Date: Mon, 28 Mar 2011 12:27:51 -0400

> As the only option that doesn't require extra traffic, round-trips, etc.  Right?

DNS lookups can overlap earlier stages of the connection but probably
introduce latency in some fraction of connections, yes. (And, when the
network filters `odd' DNS lookups then we have big problems.)

DNS chain embedding in certificates can be latency free, but has
unfortunate deployment problems.

Otherwise, yes, everything except high-freq certs is problematic.

AGL