[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Ryan Sleevi]

On Thu, Aug 22, 2019 at 1:46 PM Christian Heutger <ch at psw.net> wrote:

> I don’t say, not to do anything. But if there are other measurements,
> which don’t enforce enterprises to adopt a not yet proven (and for reasons
> rejected) way of performing “updates” (which finally also updating certs
> is), in this kind automation, it’s better to choose such measurements.
>

Again, there is zero requirement to adopt any form of automation - whether
automation of certificate deployment (e.g. Puppet) or through automation of
issuance (e.g. RFC 8555). While both are recommended, it's not correct to
suggest this ballot does anything to require them. Organizations are more
than capable of making a change on an annual basis.


>    - This is a much needed, preventative measure. It's unconscionable to
>    suggest that it's inappropriate to take measures that are known to secure
>    users are sites, and instead wait for the compromises, which happen on a
>    regular basis.
>
>
>
> Thanks for confirming, that it’s a preventive measure.
>

Everything we do, within the CA/Browser Forum, that improves security is a
preventative measure. The Baseline Requirements are a preventative measure
to prevent CAs from issuing certificates that harm users, by describing how
to correctly issue certificates. Reactive measures, sometimes called
"detective" measures, do not reduce probability nor improve security - they
merely deal with harm once it has been caused.

As the Ballot notes, this is the starting point for discussion. As noted by
supporters of the ballot, there's real security risk in the reuse of
validation of information, and so I would expect that it's not unreasonable
to see that time period further reduced - potentially on an increment of
allowing the reuse of domain validation for 30 days, initially (as we do
for Random Numbers and Response Tokens), and then, eventually, requiring a
unique domain validation for certificates issued. However, that should not
be conflated with requiring automation nor reducing lifetimes - that's
something entirely separate.


>
>    - You are correct. Browsers do not trust audits to detect or prevent
>    these issues. Audits are not a preventative measure, they are defense in
>    depth. There have been multiple auditing firms that have been distrusted
>    from providing audit reports to browsers, and there have been years of
>    efforts to improve these issues. However, audits are merely a component of
>    a holistic security story. Relying on audits alone is not, nor has it ever
>    been, a sensible security practice.
>
>
>
> Thanks again for confirming. Any management system is based on audits, any
> IAF organized ISO certification is based on audits. So if the audit system
> does not work in your point of view, it should be improved. Auditors need
> to be chosen on a trust base, otherwise all this audit scheme is unusable.
>

I agree, and many other browsers do as well, that there are many concerns
with the current scheme. Audits can be used for many things. In your
example, you discussed certification audits, but those should be recognized
as different from attestation audits, or from second-party audits, or from
the many other types of audits that exist. While the Root Program members
of the CA/Browser Forum happen to use a particular approach presently, it's
been well discussed in the Forum that such approaches may need to change.

Our approach to security is to treat it as a holistic problem. There are
many benefits to improving audits. However, those improvements will not
reduce the risks that reducing lifetimes does, nor will it provide the
necessary agility. As with any system, one should approach it with a
holistic mindset. Similarly, one should not let the perfect be the enemy of
the good, nor should one let other areas wither in order to improve just
one. We're all in this together to improve.


>
>    - As noted, "correction" involves both addressing existing
>    certificates that exist out there and having CAs ensure no new certificates
>    with the issue are issued. Addressing existing certificates is /only/
>    reliably addressable on the Internet via expiration. No other technology
>    has been shown to be consistency reliable for a wide-variety of users, on a
>    wide variety of networks. I would be shocked if the organizations opposed
>    to this would find it acceptable if all of their user data may be
>    accessible or exposed for 27 months, and yet that is the current risk.
>    Similarly, I would be shocked if organizations opposed found it acceptable
>    that an attacker who compromised their system for a few minutes would be
>    able to persist the attack, and attack all traffic, for 4.5 years. Yet that
>    is the world today.
>
>
>
> Again, therefor revocation as a mechanism exist and if it’s not working
> well (yet), it need to be improved. Expiration is no correction mechanism,
> as otherwise you run in the infinite loop of being forced by yourself to
> lower down validity period down to days, hours, minutes to be able to fix a
> few minutes attack for the next minute, latest hour or day.
>

Yup. This is a well studied problem of public key infrastructures, and has
been known for decades. My favorite work to reference on this topic is is
Dan Geer's talk on this:
https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html In the end,
Browser root programs are all about managing risk to users. Right now, the
long lifetimes represent an unacceptable risk, and so they will be reduced.
The challenges of that reduction - such as requiring annual replacement of
certificates instead of once every 27 months - are worth it.

Part of this evaluation is recognizing that the ecosystem is already well
on its way. For example, 94.2% of the still valid certificates and
precertificates are issued with a period less than or equal to 13 months.
Only 6.43% of certificates & precertificates are potentially affected. The
ecosystem is well on its way for recognizing long-lifetime certificates are
a huge risk, and unfortunately, the only way to reduce that risk for
everyone is to mandate a maximum.


> So are you able to provide the validation period, you expect, at the end,
> would be able to fix the problems you arise? Improving certificate
> lifetimes by reducing looks like a process being kicked off, which should
> have an expectable end but is still working on. In the discussions two
> years ago, there I’m still not seeing any positive result of reducing
> lifetime from 3 to 2 years, I remember I read anything about days (7 or
> sth. like that), is this the goal, you’re working on?
>

Browsers, and users, have seen huge benefits from the reduction in
lifetime. I can understand that, as a server operator, those benefits may
not be obvious, despite the protection against certain risks. For example,
the ecosystem was able to move away from trusting an incredibly risky CA in
a timely fashion, in part, because as certificates came up for renewal,
they could be replaced with certificates from a CA not being distrusted.
We'll continue to see benefits like those outlined in the original post.

You're correct, these benefits continue to accumulate as we reduce further,
and thus, it's always good to invest in automation of issuance or, if
automatically issued certificates is undesirable, automation in deployment.
Organizations will find their costs lowered and their systems more secured
through this.

As I noted earlier, the next steps will be to reduce the reuse of domain
validation information. Luckily, many solutions exist for this, and
automation is not required here, even if it was reduced to NO reuse of
information. That's great news!

I'm sure, as the ecosystem evolves, it may also be necessary to revisit
further reductions in the maximum lifetime. However, based on the current
information, that doesn't seem necessary to start worrying about right now.
As always, though, the important thing to remember is that the Internet
evolves and moves on as new threats and new understanding comes about.

Thanks for your active engagement here! It's been a great opportunity to
share and educate some of why this is an important next step that browsers
need to take to help secure users, and how sites will benefit from the
improved security and reduced risk that is afforded by reduced lifetimes!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190822/f7364680/attachment.html>