4

After reading a blog post about the new Roughtime protocol, I am not convinced of the original premise that shorter certificate lifetimes increase security. The claim is that a shorter time somehow reduces the exposure if a secret key is compromised. But how realistic is that scenario?

If the crypto protocol is weak and that’s how the key was compromised, changing the key for a new equally weak one is meaningless. Conversely, if the protocol is good, an attacker will only be able to compromise the secret key from breaching the system (or by exploiting weak people.) And we know from long experience with breaches that the first thing any attacker does is to open a back door in order to retain access if their originally exploited vulnerability is closed. The amount of time between a breach and the back-dooring process is usually measured in seconds or minutes, which a rotation policy likely won’t help.

We’ve finally begun to accept with passwords that frequent rotation is pointless (and risky). The NIST recommendations are evidence of that shift. Believing in frequent rotations for certificates seems like a superstitious holdover from the 1980s ideas of security.

So I’m asking for evidence. Have there been any studies on the efficacy of short-lived certificates as a security measure? Is there any proof that frequent certificate rotations improve security instead of simply causing frustrating inconveniences (and significant downtime as certificates expire) for all concerned? Another way to ask the question is what are the actual benefits a short certificate rotation period provides?

John Deters
  • 33,650
  • 3
  • 57
  • 110
  • 8
    I think it is more about the converse: long expiration times are a problem. – schroeder Sep 22 '18 at 19:52
  • 1
    I agree with schroeder. Given that the certificate revocation process does not properly work, there is a difference in the amount of harm which can be done if the certificate is still valid for a week after you've detected (and fixed) the compromise or if it is still valid for half a year. And, not only a direct compromise by an attacker might be a problem but also change of ownership of a domain where the old owner might still have a valid certificate for the newly owned domain. – Steffen Ullrich Sep 22 '18 at 20:01
  • 1
    So one positive is if a CA issued a million certs over the year, and 1% were revoked, the CRL would be 10000 long. If certs last only 60 days, the CRLs would only be 1666 long. Regardless of whether or not the CRL process is any good, it’s what we have to deal with today. That’s valid. – John Deters Sep 22 '18 at 20:21
  • 2
    ePassports have very short lived leaf certificates to access the fingerprints for exactly the reason that revocation doesn't work for ePassports (asking and parsing a CRL is "a bit tricky" on Smart Cards, and OCSP requires a full online connection). That way stealing an inspection system (with the private key) doesn't compromise the security as much as if long lived certs were used. The problem with changing passwords all the time is that *we cannot frickin' remember the passwords*. Computers on the other hand have pretty strong memory. – Maarten Bodewes Sep 22 '18 at 20:27
  • 1
    That article also provides no data that the 6% of TLS errors due to clock skew is caused by NTP man-in-the-middle attacks -- ie they have not convinced me that their protocol is solving a problem that needs to be solved. – Mike Ounsworth Sep 23 '18 at 22:55

2 Answers2

3

One document I can't resist from showing you here is draft-nir-saag-star by Yoav Nir (the chair of ACME working group) and the subsequent discussion across the saag mailing list.

An important issue Yoav rises there is that neither OCSP responders nor CRL distribution points are widely recognized as reliable network parties. I mean, there's obviously no evidence they are constantly down either, but, given the soft-fail approach currently in use, there's no need for a current certificate authority infrastructure to be available and monitored 24/7, which makes the transition to hard-fail (with the likes of Must-Staple, etc.) much harder.

And, anyway, CRL and OCSP both constitute an additional single point of failure, while a today's Internet service tries its best to avoid those at all.

As a matter of fact, a short-lived certificate is only good if the rotation is automated; however, for a sufficiently scalable network service, deployed across tens to hundreds to thousands physical and/or virtual instances, this holds true.

Also a few quick remarks on the rest of the question,

Conversely, if the protocol is good, an attacker will only be able to compromise the secret key from breaching the system

— But not necessarily the system where the certificate and the private key are deployed in order to handle the production traffic. Might as well be the central Ansible server, or its network storage, or a server used for certificate renewal, or anything else. Might also be just a small portion of the production servers, not even in use (e.g. when a network service is deployed over a few cloud providers and one of those has allowed for a breach). In some (more outdated?) threat models it might have also been a (stolen) personal laptop of an employee responsible for certificate renewal.

In all the above cases there won't be any immediate benefit to an attacker for installing a backdoor, while they can still easily go away with the private key and use it for MitM, etc.

We’ve finally begun to accept with passwords that frequent rotation is pointless (and risky)

Well, not exactly. E.g. NIST SP 800-63B suggests that "verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)", where a memorized secret is "a type of authenticator comprised of a character string intended to be memorized or memorable by the subscriber, permitting the subscriber to demonstrate something they know as part of an authentication process".

However, this doesn't apply to a private key which is never ever expected to be memorized or memorable in any sane contemporary usage scenario. As a matter of fact, there are also drawbacks of a frequent certificate rotation (such as the need to properly automate things), but those are not even close to the disadvantages of a frequent memorable passwords' rotation.

ximaera
  • 3,395
  • 8
  • 23
2

Revocation is easier.

If you do nothing at all, the certificate will get invalid by itself after a short period of time, rendering it less dangerous than one with a long lifetime.

When you actually employ revocation infrastructure, you get huge certificate revocation lists (CRL) and much traffic at OCSP servers to verify if a certificate is revoced. This is a lot of management efford and infrastructure cost, which e.g. may have prevented letsencrypt.
So the they use a short lifetime for certificates, such that their revocation lists are always very short, as they can purge expired certificates from the lists.

allo
  • 3,173
  • 11
  • 24