Bulletproof TLS Newsletter

Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Received monthly by more than 50,000 subscribers. Written by Ivan Ristić.

Certification Authority Authorization (CAA) is a good example of a technology that’s slow and steady. Originally conceived in 2013 as RFC 6844, it was adopted by the CA/Browser Forum and mandated for all CAs in 2017, and eventually brought to its current shape in 2019 as RFC 8659. Although not perfect, it gets the job done, and support for it continues to grow.

If you’re not already familiar with CAA, in essence it’s a mechanism that enables domain owners to advertise a certificate issuance policy, in effect controlling which CAs are allowed to issue certificates for their properties. It builds on top of DNS and relies on a new resource record type.

The original form of CAA has been extended to satisfy two additional use cases. First, the CA/Browser Forum added the contactemail and contactphone extensions to enable policies to communicate contact information for those in charge of certificate issuance.

Separately, the ACME Working Group realized that there wasn’t enough permission granularity in the original CAA design. To remedy that, the group added the accounturi extension to enable targeting specific customer accounts within CAs, thus reducing the attack surface even further. They also added the validationmethods extension to control which validation methods can be used for certificate issuance. This can be useful, for example, if you want to centralize issuance using only DNS validation methods. For the documentation, refer to RFC 8657. These extensions are not yet mandated by CA/Browser Forum, which means that CAs don’t have to support them. However, that’s not necessarily terrible, because you only need them to be supported by the CA you’re using. Let’s Encrypt supports the extensions as of December 2022. You can read more about that in an article on Hugo Landau’s website.

But that’s not all. There are several new efforts in progress to adapt CAA to support additional functionality and certificate types.

For example, BIMI is a recent effort to bring company logos to email. This standard, currently in the early stages of deployment, relies on CAA and the new issuevmc property to control issuance of Verified Mark Certificates.

More recently, the Limited Additional Mechanisms for PKIX and SMIME (LAMPS) Working Group voted to adopt a new RFC, one that specifies a new property called issuemail, which controls issuance of S/MIME certificates.

Finally, it’s very early, but there is interest in expanding CAA so that it can control issuance of certificates bound to IP addresses. The IETF mailing list recently received a message from Antonios Chariton, who’s working on a draft of the new specification.

Short news

Here are some things that caught our attention since the previous newsletter:

• Luxemburk and Čejka published their work in the field of encrypted traffic classification in an article titled “Fine-Grained TLS Services Classification with Reject Option.”
• Tanya Verma wrote about Cloudflare’s work on Geo Key Manager v2, which is designed to support control of distribution of private keys by geographic location.
• Neil Madden appeared on the Cryptography FM #23 podcast to discuss Java’s Psychic Signatures (last year’s discoveries about botched ECDSA signing).
• In his blog post titled “Never DIY Your PKI,” J. Hunter Hawke talks about why building your own PKI is too much work.
• GitHub suffered a security breach, with three of its code-signing certificates compromised. However, the certificates were password protected, which prevented malicious use.
• The Calgary Internet Exchange (YYCIX) deployed ASPA filtering on a public peering fabric. The YYCIX Route Servers drop ASPA-invalid BGP routes in order to protect multilateral peers.
• NIST announced FIPS 186-5, which, for the first time, allows the use of the Edwards Curve Digital Signature Algorithm (EdDSA).
• The Open Source Cryptography Workshop is taking place on March 30, 2023, in Tokyo, the day after the Real World Cryptography (RWC) symposium. Registration for RWC is now open.
• OpenSSL patched several vulnerabilities, the most severe one marked High.
• Chrome developers announced that they will deprecate and remove the block-all-mixed-content CSP directive, which is rarely used these days.
• The Sigstore project’s blog included a post about the project’s work securing the Java ecosystem. Sigstore released its production for Python in January 2023, offering a new effort to digitally secure the software component supply chain.
• Wladimir Palant investigated the curious case of South Korean banks installing their own root CA certificates onto customers’ computers.
• Shikhar Gupta wrote about bypassing certificate pinning on Android in a blog post.
• Chrome continues to vary its TLS handshake with TLS extension permutation. These changes are an effort to defeat fingerprinting and ecosystem ossification.
• NIST selected the Ascon family in its lightweight cryptography competition and standardization.
• Frank Denis compiled OpenSSL 3 for WebAssembly.
• Neil Madden reviewed The Joy of Cryptography, a free book by Mike Rosulek of Oregon State University.
• The Brave Privacy Team wrote about Brave’s efforts to always use HTTPS when it’s available.
• A post on Elttam’s blog discussed its research into practical exploitation of weak (noncryptographic) random number generators in Java.
• Mike Malone wrote a blog post about using short-lived certificates to avoid having to deal with revocation.
• Mammoth, one of the oldest CT logs, run by Sectigo, reached the end of its life after suffering an availability incident that exceeded the allowed downtime.
• Andrew Ayer released a new tool called CRL Watch, which highlights CA operators with CRL delivery problems.