Merkle Tree Certificates: Solving the Post-Quantum Certificate Problem in TLS
Post-quantum cryptography is often described as an algorithm migration: replace today’s cryptography with quantum-safe alternatives and move on. But on the web, the consequences go much deeper. Post-quantum signatures are significantly larger, and simply inserting them into the existing Web PKI challenges the performance and bandwidth assumptions on which TLS and certificate chains were built. PQC does not just change the algorithms: It changes the economics and in consequence the entire architecture.
Merkle Tree Certificates try to maintain the economics by redesigning the handshake. Instead of making every server repeatedly transmit large signatures, they move much of that cost into a public log and let servers prove that their certificate is part of it. This talk explores why post-quantum cryptography forces us to rethink some long-standing assumptions of the Web PKI and how Merkle Tree Certificates work.
Given Merkle Tree Certificates are step by step moving into the pole position to become the new standard, it is important to understand what a transition to this model could mean for the future of TLS and the web.
AI Summary
Disclaimer: This session information was generated with the help of AI.
The information has been reviewed and refined by the Swiss Cyber Storm team before publishing.
Benjamin Rothenberger argues that post-quantum signatures are technically ready but too large for the Web Public Key Infrastructure (PKI): dropping them into today’s Transport Layer Security (TLS) handshake inflates authentication data from about 450 bytes to 14.7 kilobytes. He explains how Merkle Tree Certificates (MTCs) replace per-certificate signatures with signed logs and compact inclusion proofs, and how hourly landmarks distributed out of band remove signatures from the handshake almost entirely. The talk weighs these gains against new ecosystem complexity and outlines early adoption by Chrome, Cloudflare, Let’s Encrypt and Apple.
Video chapters
0:00Post-quantum threat to TLS4:20Signature overhead in the TLS handshake8:22Merkle Tree Certificates and issuance logs10:11Merkle trees, checkpoints and inclusion proofs16:03Landmarks and out-of-band distribution18:43Standalone and landmark-relative certificates20:38Impact on the Web PKI23:43Industry adoption and outlook26:24Questions and answers
Key facts
- A classical elliptic-curve TLS handshake transmits about 450 bytes for authentication, whereas plugging in Dilithium-based post-quantum signatures raises this to about 14.7 kilobytes, exceeding the 14.6-kilobyte initial TCP congestion window.
- QUIC's amplification protection prevents a server from sending more than three times the traffic the client has sent so far, so larger certificate chains also slow down QUIC handshakes.
- According to the speaker, around 67% of human traffic to Cloudflare already uses a hybrid post-quantum key exchange, adding roughly one kilobyte in each direction.
- With landmark-relative Merkle Tree Certificates, the authentication data in the handshake falls to about 4.5 kilobytes, back under the initial congestion window.
- Let's Encrypt, which issues more than half of all public certificates, has named Merkle Tree Certificates as its way forward, and Chrome and Cloudflare have announced a larger-scale experiment.
Ideas
- Post-quantum confidentiality is largely solved by hybrid key encapsulation, so the real TLS bottleneck is authentication, where five signatures and two public keys must be transmitted in every handshake.
- Merkle Tree Certificates shift the certificate authority from signing individual certificates to signing a checkpoint of its issuance log, so one signature covers many certificates and the server supplies only an inclusion proof of sibling hashes.
- Landmarks, signed log snapshots produced roughly every hour and delivered to browsers through an authenticated out-of-band update, enable landmark-relative certificates that carry no certificate authority or transparency signatures on the wire.
- Each endpoint needs both a standalone certificate, which works for offline clients, and a landmark-relative certificate, which is efficient but only usable once the next landmark has been published and fetched.
- Fewer bytes in the handshake come at the cost of more moving parts: every certificate authority must operate its own log, browsers must hold extra state, and supporting drafts are still immature.
Keywords
- Merkle Tree Certificates
- quantum computing
- post-quantum signatures
- TLS
- TLS authentication
- Web PKI
- certificate transparency
Quotes
- “Post-quantum signatures are actually ready to be used but the internet cannot afford them.”
- “The idea is to stop sending what the client already trusts.”
- “Given that we sign the log and not the certificate anymore, one signature can actually cover many many different certificates.”
- “We achieve fewer bites in the handshake but in the ecosystem around it there is actually more moving parts.”
Recommendations
- Prioritize migrating TLS key exchange to hybrid post-quantum key encapsulation now, because harvest-now-decrypt-later attacks make confidentiality the urgent problem, while authentication only becomes attackable once a quantum computer exists.
- Do not plan post-quantum authentication as a simple algorithm swap; account for handshake size, congestion-window and QUIC amplification effects when assessing performance and compatibility.
- Inferred from the talk: track the Merkle Tree Certificates standardization and the ecosystem bootstrapping expected early next year, as the speaker stresses the approach is not yet ready for production but represents a major change to the Web PKI.
Resources
- Merkle Tree Certificates (IETF Internet-Draft) — Specification — The primary reference for understanding how Merkle Tree Certificates are expected to replace signature-heavy certificate chains in post-quantum TLS.
- Chrome and Cloudflare Merkle Tree Certificates experiment — Experiment — Shows the current state of real-world deployment and gives defenders an early view of how the new model behaves at scale.
About the speaker
Benjamin Rothenberger
Principal Security Consultant
at
Zühlke
Dr. Benjamin Rothenberger is a Principal Security Consultant at Zühlke Engineering AG, specializing in applied cryptography, post-quantum cryptography (PQC), and security architecture.
He holds a PhD in Computer Science from ETH Zürich, where his research focused on secure networked systems, cryptographic protocols, and secure Internet architectures such as SCION.
Read more …
Read more …