[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Ryan Sleevi]

On Wed, Aug 28, 2019 at 2:10 AM Christian Heutger <ch at psw.net> wrote:

> Hi,
>
> I‘m currently a bit spare of time, but OCSP stapling as a solution I tried
> in my private 100%+ researches for my private sites and I activated it
> without any issues in nginx, one of the most wide spread and reliable web
> server. Postfix (instead of Exim) was my only drawback, not to support
> stapling yet. For sure, if it would be a requirement, software would really
> quick adopt.
>

I think this, again, highlights how site operators may be ill-informed
about the consequences of their decisions and the impact on the ecosystem.

While nginx is well-beloved and respected by many, its OCSP Stapling
support is simply not robust to address the problems that you and Dimitris
have suggested revocation can mitigate. Among the long-list of
implementation issues that nginx's stapling implementation has, the most
notable, which we at Google have seen a non-trivial amount of breakage for
Chrome and Google users, is that nginx uses a deferred loading approach for
OCSP responses which cause it to continuously serve requests while waiting
for a response to fetch. Similarly, its logic for updating and maintaining
those responses has a number of sharp edges that can, and quickly does,
lead to a site being unavailable when it's unable to obtain a fresh
response.

Now, while you personally may not encounter this in your personal site,
because it lacks the volume of traffic for this to matter, I can assure you
that when you talk about a notion of requiring every site to 100% support
OCSP stapling all of the time, and for clients to always require it, and to
support the *automation* necessary to ensure those responses are reasonably
fetched, it rapidly becomes apparent that adjusting certificate lifetimes
becomes far more meaningful and far less problematic.

There is no honest, earnest way that one can argue that automating OCSP
response fetching is good, while automating certificate revocation is bad,
while making the argument against automation, as has been done here.
Certainly, one cannot suggest with any degree of intellectual honesty that
requiring OCSP stapling for 100% of the Web is reasonable within a six
month timeframe, and thus it does not benefit anyone to continue to paint
such a solution as somehow a realistic solution or timeframe. This is
especially true when such myopic focus continues to ignore the many
benefits independent of revocation, or that revocation itself, when
exercised, still presents numerous challenges to site operators, in terms
of replacing and revalidating certificates, for which reduced lifetimes
streamline and improve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190828/e2e2ab0b/attachment.html>