Cryptography & Security Newsletter

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić.

Judging from recent events, the focus in the next couple of years will be on adopting significantly reduced certificate lifetimes. We’ve known for a while that Google wants to reduce certificate lifetimes to ninety days, but earlier this year, Apple surprised everyone by pushing for as little as forty-five days (forty-seven in the latest proposal). Unlike Apple and Google, which are forcing everyone to follow their direction, Let’s Encrypt is approaching the problem from the other end by offering us a choice.

In his end-of-year letter, Josh Aas, the founder and executive director of the Internet Security Research Group (ISRG), announced plans for six-day certificates. Happy 2025: short-life certificates for everyone!

Although this is an exciting development—because we need to explore how low we can go—providing short-lived certificates doesn’t come for free. Any property that adopts them will increase Let’s Encrypt’s workload by a factor of 20, at least. Today, with 90-day certificates, we rotate them every 60 days. With six-day certificates, you’d want to get a new certificate at least every 3 days, or 20x more often. In fact, because there is not much room for error, it would probably be prudent to get a new certificate every day, or 60x more often.

Technically, short-lived certificates will improve security, but, in reality, most properties won’t benefit because they don’t have much to protect in the first place and no one will be attacking them anyway. Thus the risk here, for Let’s Encrypt, is that they will have to do much more work for no practical gain. Just imagine a very popular ACME client switching to short-lived certificates by default. Tricky.

There are other costs, for example a significantly reduced margin of error for web sites. Today, if something goes wrong with your renewal, you’re chilled, because you have 30 days to get things right. With short-lived certificates, you have only 2-3 days, at most 5. Imagine Let’s Encrypt going down for an extended period of time… that would mean coming back to a thundering herd of ACME clients desperately trying to renew, causing a big spike in Let’s Encrypt’s load. If we want to go down this route, we need three free (and no-registration) CAs, each capable of supporting the entire world. And we need all ACME clients configured to use them.

Is clock skew going to be a problem? It’s well known that clients often don’t have accurate clocks. If they’re significantly off, certificates can be interpreted as expired (or not yet valid), leading to validation errors. In 2015, Google reported that clock skew causes 20% of HSTS errors. On the other hand, when Meta switched to 10-day certificates in 2023, they reported no noticeable increase in TLS handshake errors. I suppose we’ll find out. If you’re planning to use short-lived certificates, it’s critical to use client-side problem monitoring via Network Error Logging, but even that won’t give you a full picture due to limited client support.

Another thing I will be worrying about is the increased load on the Certificate Transparency (CT) ecosystem. Since its deployment in 2018, CT has done wonders for the security of Internet PKI. But the ecosystem is fragile, with not enough providers and servers that often struggle to handle the ever-increasing number of certificates. If the number of issued certificates were to significantly increase today, the system wouldn’t be able to handle it. In addition, a number of non-commercial monitors would probably give up, as the costs of monitoring would rocket.

Post-Quantum Cryptography Adoption

Following the recent official adoption by NIST of new algorithms resistant to quantum computers, there is a frenzy of activity related to post-quantum cryptography.

• The Australian Signals Directorate has updated its cryptography guidelines for the post-quantum era, outlining an aggressive schedule that includes deprecation of the vulnerable primitives by 2030. That’s five years sooner than NIST’s and NSA’s plans. Interestingly, unlike the other recommendations, the directorate is planning to preemptively deprecate SHA-224 and SHA-256, even though it’s currently believed that these two will not be significantly affected by quantum computers.
• Whenever I think of hash security, I am reminded of Valerie’s excellent overview.
• Platforms and libraries are busy updating with support for the new post-quantum cryptography. Go added support for ML-KEM in 1.24. Java will release the updates with JDK 24 (which will be released in March 2025), but the new primitives are already in Bouncy Castle 1.79. AWS LibCrypto (AWS-LC) also added post-quantum support as well as underwent FIPS validation.
• In the meantime, progress to building a cryptographically-relevant quantum computer (CRQC) continues with Google announcing Willow, their next-generation quantum chip. With this chip, Google is claiming a breakthrough—exponential error reduction with the increase of the number of qubits. Willow is the topic of a new Security. Cryptography. Whatever. podcast with Samuel Jaques and John Schanck.
• According to the 2024 version of Global Risk Institute’s Quantum Threat Timeline Report, we are roughly about 20 years away from a CRQC.
• The transition is going well; at the time of writing, about 30% of Cloudflare’s traffic uses quantum-safe encryption.