[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Ryan Sleevi]

On Tue, Aug 27, 2019 at 9:23 AM Christian Heutger <ch at psw.net> wrote:

> > For example, I don't think we'll ever find consensus when a CA is
> arguing that users should have to sacrifice their privacy and disclose
> their browsing activities to CAs to be secure online, which is what you've
> clearly advocated. That sort of fundamental misunderstanding suggests a
> misunderstanding of the role CAs play, and is not easily corrected, no
> matter how carefully dispelled.
>
>
>
> OCSP stapling doesn’t require to do so.
>

I appreciate you raising OCSP stapling, because it's a great example of how
a service-focused mindset ignores the ecosystem impact and challenges, and
demonstrates the high costs involved with extract value, relevant to the
high value available via certificate lifetimes.

The thesis of Dimitris' argument is that if we had a perfect revocation
system, we would not need to address validity periods. My response to
Dimitris indicates why a perfect revocation system is unrealistic and
impractical. If I understand your argument, it is that OCSP stapling could
be that perfect revocation system, at least with respect to privacy.

Recall that the objective of reducing certificate lifetimes is to protect
users and serve users needs. Users want to ensure the information is fresh,
accurate, and reliable, because that ensures that their information is
adequately protected in transit.

There is no way these users can "force" servers to support OCSP stapling.
The user's options are:
1) Fetch an OCSP response or CRL, both of which compromise privacy and
performance
2) Refuse to connect to a server that does not support OCSP stapling.

We can assume that #1 is unacceptable for privacy and performance reasons.
#2 is impractical, for a variety of reasons:
1) The majority of servers do not support OCSP stapling today
2) The majority of server software does not support OCSP stapling today in
a way that meets user needs
  - I'm only aware of two servers that support OCSP stapling robustly:
Microsoft IIS and Caddy Server.
  - All other implementations create the risk of significant service
disruptions or would result in severe configuration errors

Now, if you were to ask any server operator individually, you'd likely find
that the cost of getting OCSP Stapling working for their server, and
working in a way that would not disrupt their site (e.g. serving expired
responses, handling timeouts/retries when fetching, working behind their
firewalls aka against best security practice), they'd argue that the
benefit is very low to them. Individually, they'd not be concerned about
their certificate being revoked, and they might argue (incorrectly) that
it's the client's responsibility to check the status, and not theirs to
provide it.

Similarly, imagine you're a server operator that does opt in to OCSP
stapling, and you did everything right. However, you don't benefit from
doing this if the client doesn't require (or perform) OCSP checking
themselves. That's because if an adversary gets a certificate, then even if
you detect it and revoke it, the adversary doesn't have to support OCSP
stapling.

Now, a naive suggestion might be to say "Ah hah, this is what OCSP
Must-Staple solves!". Except OCSP Must-Staple similarly works against users
and site operators. Unless all CAs set OCSP Must-Staple, which they
absolutely should not do without robust OCSP Stapling solutions not only
implemented (which they aren't today) but also deployed (which they
definitely aren't today), or all clients require Stapling, OCSP Must-Staple
doesn't actually solve anything for the Defender, because the Attacker will
just get a certificate without this.

So we're in a situation where:
1) A well-informed site that wants to defend against maliciousness cannot,
because:
  a) Other sites' behaviours negatively impacts them (e.g. the lack of
their support for Stapling, preventing clients from implementing stapling)
  b) Other CAs' behaviours negatively impact them (e.g. CAs issuing without
Must-Staple)
  c) Their own CA's behaviours with respect to the OCSP responses
negatively impacts them (e.g. OCSP responses that are 10K in size, as some
CAs' responses are), and absent collective action or requirements by
browsers, a single site operator cannot convince any CAs to change or
improve.
2) A user that wants to defend against maliciousness cannot, because:
  a) Sites don't have incentives to adopt OCSP stapling (e.g. it's all cost
to them, with no benefit from Attackers)
  b) CAs don't have incentives to adopt OCSP stapling (e.g. deploying
Must-Staple would simply break clients, because the server situation is
awful)

To support OCSP stapling, you'd need
1) Server software to be updated to actually support robust OCSP stapling
2) Server operators to deploy updated web servers (which can be very hard)
3) Browsers willing to break any site that didn't comply, which requires a
majority of #1 and #2 to be solved.

Now, in all of this, we haven't talked about the role CAs could be playing,
but to date, have not, in addressing some of those concerns. It should be
obvious that CAs could be doing stuff here, but even more than expiration,
the articulation of benefits here is hard.

And equally important is that even with this perfect solution, of
ubiquitous and reliable OCSP stapling, it:
1) Doesn't address all of the issues highlighted that expiration does
address
2) Requires significantly more investment from a significantly larger
amount of sites and players

The Web PKI is full of stories like this, where users and well-meaning
server operators are harmed by the CAs and the recalcitrant customers, such
as yourself, and wholly rely on Browsers to do the Right Thing by the user
and to protect their interests. I understand why technologies like
OCSP-Stapling or OCSP Must-Staple seem appealing, and while I've only
focused on a small section of revocation, the reality is that there is
nothing that meaningfully addresses the problems.

You've suggested, previously, that it's short-sighted or not weighing the
costs versus benefits. I can only assure you that in the years that we've
been talking about this, these concerns have been carefully weighed, and
they've absolutely been communicated to CAs in the past. We need to move
forward, and we need to do the right thing for users. Certainly, Chrome
will do the right thing for users, but our hope is that as an industry, we
can recognize that our inaction is causing harm and that nothing as
comprehensive, as beneficial, and as low cost exists to address so many of
these issues.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190827/7a46b077/attachment.html>