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ć.

Practical TLS and PKI Training Join us on this remote, tutor-led training that covers the theory and practice of SSL/TLS and Internet PKI. Four half-days, packed with information. This practical training course will take you through everything you need to know to deploy secure servers and design secure web applications. Based on our book Bulletproof TLS and PKI. Next public sesions: US/Europe: 22-25 September 2025

Internet PKI to Integrate DNSSEC

We use digital certificates to secure our network communication, but have you ever considered that the issuance of the certificates themselves is essentially trust on first use (TOFU)? This acronym is commonly used to refer to a trust model that’s bootstrapped on the assumption that the first interaction is with the intended party, but this assumption is not fully validated.

You may be more familiar with TOFU from SSH, in which clients remember servers’ keys when they connect for the first time. This works because it’s normally very unlikely that someone will interfere with this very first connection. That’s because it usually happens immediately after a new server is booted for the first time, which is an event that’s under your control.

It’s less obvious that the entirety of internet PKI operates in the same way, because we normally interact with digital certificates and there is an assumption that they have been obtained securely. However, in practice, this is again TOFU. When a certificate is requested, behind the scenes, CAs use insecure communication to validate domain control. To be clear, this does help, because there is now only one initial insecure connection per certificate, after which the entire world can connect securely.

This trust model, on which internet PKI is based, works—until it is attacked. Any party that can intercept the communication between the CA and an IP address behind a domain name can get a fraudulent certificate. The attack vectors include man-in-the-middle attacks, BGP hijacking, and exploitation of dangling DNS issues.

Work has been under way to improve this situation, starting with Multi-Perspective Issuance Corroboration (MPIC), which has been adopted by the CA/Browser Forum and will become mandatory in September 2025. This technique raises the bar by enforcing multiple geographically dispersed vantage points for CAs’ DNS queries and validation traffic. Although it helps, MPIC is not a foolproof solution.

Cryptographically Secured Domain Validation

But we can do better than that. In their paper titled Cryptographically-Secured Domain Validation, a group of researchers proposes measures to close the remaining security gaps. Their approach is threefold: (1) Devise a set of new ACME methods for cryptographic domain validation; (2) extend CAA to enable property owners to require increased security; and (3) rely on DNSSEC to deliver authentic CAA records.

Sounds great! When can we have it? Actually, some aspects of this proposal have already been adopted. In ballot SC-085v2, the CA/Browser forum decided to make DNSSEC validation mandatory. This in itself is an improvement and allows anyone to use ACME Account Binding (RFC 8657) today for authenticated issuance. RFC 8657 itself is not yet mandatory, but there are indications that it will be adopted by the CA/Browser Forum. The rest of the proposal for cryptographic domain validation will hopefully follow over time. The RFC to update CAA is already in progress.

Convergence of Internet PKI and DNSSEC?

It feels like we’re on the verge of convergence of the internet PKI and DNSSEC trust models. For years, internet PKI has been developed under the assumption that DNS cannot be trusted. This was not necessarily because DNS couldn’t be secured at the technical level (although, admittedly, DNSSEC can be quite clunky) but because governments, which ultimately control DNS, can’t be trusted in the long term. As a result of this decision, a lot of effort went into securing internet PKI, an effort that could have potentially been avoided by relying on DNSSEC. However, if the models are unified, we may end up with a trust model that’s fully authenticated (DNSSEC) but comes with transparency and enables property owners to maintain control (internet PKI). Exciting.

Other News

• The European Union has published its guidelines for migration to post-quantum cryptography. The timelines are as follows: triage by the end of 2026, migration of high-risk properties by the end of 2030, and migration of the remaining properties by the end of 2035.
• Researchers have discovered a novel tracking method, used by Meta and Yandex, that affected the privacy and security of potentially billions of Android users. The clever technique relied on the sharing of information between (1) websites running in browsers and (2) native apps that were designed especially for this purpose.
• The next release of Apple’s operating system, due this fall, will provide post-quantum security for TLS by default for all network communications that rely on the modern, recommended APIs. This video from WWDC25 has more information.
• Frank Denis makes a passionate plea for better user interfaces for OpenSSL cipher suite selection.
• The Electronic Frontier Foundation is weighing in on the European Union’s “encryption roadmap,” which continues to push for access to private communication.
• KEYMASTER talks about certificate linting for private PKIs.
• Twitter has a new protocol for encrypted direct messages, but it’s not great. Matthew Garrett and Matthew Green explain in more detail.
• New Java and C# releases of the Bouncy Castle library improve post-quantum cryptography and interoperability.
• IBM says it will deliver Quantum Starling—a large-scale, fault-tolerant quantum computer—by 2029.
• If you’d like to learn more about quantum computation, take a look at Peter Shor’s lecture notes from 2022.
• Matthew McPherrin has dug into Mozilla’s telemetry data to show us the most often encountered public CAs in Firefox.
• Ryan Hurst is not happy with CAs and thinks that there’s a disconnect between those who are making decisions and those who are dealing with the consequences. However, though it’s historically true that CAs had to be forced to improve, it’s worth noting that the ecosystem is ultimately governed by the browsers and other major root programs.
• The ACME Renewal Information (ARI) extension has been published as RFC 9773. When this extension is supported, CAs can signal to clients the need to rotate certificates earlier—for example, if they need to be revoked.
• A Trail of Bits blog post by Benjamin Samuels highlights that private key compromise is the single biggest cause of cryptocurrency hacks, at 43.8 percent. More importantly, the blog post focuses on how protocols can be designed to resist this class of attack.
• Latacora’s Cryptographic Right Answers: Post Quantum Edition is nearly a year old, but it’s still a good read.
• Logjumps is a recently discovered technique for modular reduction over large prime fields.
• Let’s Encrypt is getting ready to issue certificates for IP addresses, but not everyone is happy about it.
• Until recently, Amazon was making its public certificates available only on its own infrastructure—but not any longer. It’s now possible to export generated certificates, for a fee.
• Cloudflare updated Orange Meets, its open-source video-calling application, with support for end-to-end encryption using Messaging Layer Security (RFC 9420).
• Greg Rubin at CryptoGotchas discusses why, in cryptography, domain separation matters.
• Daniel Stenberg’s curl supports 11 TLS backends; 6 of those are OpenSSL forks.