The term on this page
- TLSTransport Layer Security
- the protocol behind the padlock in your browser
Also mentioned
ECDSAECDSAElliptic Curve Digital Signature AlgorithmElliptic Curve Digital Signature Algorithm, a widely deployed signature scheme based on elliptic-curve cryptography, offering strong security with compact keys.Read the full entry, ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry, PQCPQCpost-quantum cryptographyCryptographic algorithms designed to run on today's classical computers while remaining secure against attacks by both classical and future quantum computers.Read the full entry are defined in the glossary.
What this is
A position paper submitted to the IAB Workshop on Accelerating the Deployment of Post-Quantum Authentication on 28 August 2026. It has not been accepted, reviewed or endorsed by anyone. We are publishing it, and every document and measurement behind it, at /proposals/tls-resumption-recheck.
A full TLS handshake sends a certificate chain and validates it: expiry, trust anchors, revocation, and whether the peer is authorised for what it asked for. A resumed connection sends none of that. Both sides carry the earlier result forward, which is exactly why it is cheap.
So what must a server re-establish before it relies on that carried-forward verdict? We went looking for the answer and could not find one.
The rule existed, and then it did not
This was written down once, on the server. RFC 6066 section 3, for TLS 1.2: "A server that implements this extension MUST NOT accept the request to resume the session if the server_name extension contains a different name."
TLS 1.3 removed it, deliberately. RFC 9846 section 4.3.11 records the decision in plain language: "there is no need for the server to associate an SNI value with the ticket." The one certificate-scope rule that survives at resumption sits on the client. On the time bound the RFC is normative but unquantified. On scope, server-side, there is nothing.
That is not a bug anyone can point at. It is an absence, and an absence does not produce one wrong answer. It produces a different answer per implementation.
Eleven identifiers, eight products, eleven years
We built the corpus: eleven CVE identifiers across eight pieces of software, September 2014 to February 2026. Apache, Envoy and stunnel each shipped their own version of the same thing, independently. curl appears four times. In five of the eleven, a party outside the current trust scope gains standing access needing no network position, and in all five the replayed verdict is a client-certificate verdict.
The repetition is the argument. This is not one vendor's mistake. It is the same question answered differently by everyone who has had to answer it alone.
One vendor has now done it twice
In January 2023 Cloudflare found revoked client certificates being honoured on resumption. It disabled resumption for mTLS, built a real fix that checks revocation at resumption, and re-enabled within weeks. That fix was correct and it was specific: it bound revocation. Two years later CVE-2025-23419 was a scope failure, which the 2023 fix did not address and was never meant to. The switch went off again, network-wide, and has stayed off. A vendor can solve this class correctly and still have no way to know what else the class contains.
Why post-quantum turns an annoyance into a decision
An ML-DSA chain with its CertificateVerify runs to about 18.4 kB against 3.5 kB for ECDSA P-256. The post-quantum server flight is 19,762 bytes against a 14,600 byte initial congestion window, so it stops fitting in the first ten packets and the server has to wait. A resumed connection sends no certificate at all.
Resumption stops being an optimisation and becomes the mechanism that decides whether post-quantum authentication is affordable. It is also the mechanism operators are switching off, because nobody can tell them what a resumed connection is allowed to skip.
| today | if it could resume | |
|---|---|---|
| Post-quantum, mutual TLS | 112.44 TB/year | 4.94 TB/year |
| Post-quantum, server authentication | 72.13 TB/year | 4.94 TB/year |
| Classical, server authentication | 13.73 TB/year | 1.09 TB/year |
The classical row is context, not the prize: 94.8% of reachable TLS domains already issue a session ticket, so almost everyone banks that saving today. The mutual-TLS row is what a rule would actually buy, because that is the population currently unable to resume safely. It is a small population, and it grows with every operator who deploys post-quantum authentication under client certificates, meets the same absence, and reaches the same safe answer.
What we measured, rather than cited
Advisories tell you what was true when they were written. We reproduced against current releases instead, each with a control so a result means the resumption path specifically:
- OpenSSL 3.6.3 accepts a resumed session carrying an expired client certificate. The control full handshake rejects it.
- nginx 1.31.4: the CVE-2025-23419 fix holds, with a control replaying the ticket at its own host to prove it was offerable.
- Go 1.27.0 re-establishes certificate expiry and trust-anchor membership on resumption, which is more than its one-line summary suggests.
- Fourteen public endpoints: 14 of 14 issue a ticket, 13 of 14 resume, and 11 of 14 already negotiate the post-quantum hybrid group.
The measurement that changed our instrument
A silent TLS connection drew a session ticket from only 8 of those 14 hosts. One HEAD request drew one from all 14. Every Google-fronted and Cloudflare-fronted name withholds its ticket until a request arrives. Measure without one and you report no resumption for a large share of the web, which is false. That finding also changed the PQC Observatory, which now measures resumption daily alongside key exchange.
What we propose
One rule, on the decision rather than the handshake path, with four ways to satisfy it and no protocol change required:
An endpoint MUST NOT rely on a replayed authentication verdict for any decision that a full authentication, performed when the verdict is first relied upon, would decide differently.
Satisfy it by re-establishing the condition from the cached session, by refusing to resume, by deferring the decision as Apache does with a 421, or by over-approximating: bind the trust configuration and the authentication policy into the resumption scope so any change forces a full handshake.
Everything is published, including what we got wrong
The paper, four supporting documents, the vulnerability corpus with the CVEs we deliberately excluded and why, the experiments and both public repositories are at /proposals/tls-resumption-recheck. The tests are in quantakrypto/tls-resumption-tests and the daily measurement in quantakrypto/pqc-observatory.
The supporting documents carry a revision record of every correction made during review, including the ones that were embarrassing: a headline count that did not survive its own recount and was deleted, a reference cited in no document that was cut, and a claim about AWS that we had attributed to the wrong evidence. That machinery is not decoration. A paper arguing that the ecosystem needs checkable answers has to be checkable itself.
If you terminate TLS and use client certificates, the practical question is narrow: mint a session ticket at one virtual host and offer it back with the SNI of a host that requires client certificates. If the second connection reports Reused and completes without asking for a certificate, a verdict crossed a boundary. Only ever do that against infrastructure you operate.
References
- RFC 6066 section 3: Server Name Indication (rfc-editor.org) - the TLS 1.2 rule this proposal is about: a server MUST NOT resume a session whose server_name has changed.
- RFC 9846 section 4.3.11: Pre-Shared Key Extension (rfc-editor.org) - where TLS 1.3 records that there is no need for the server to associate an SNI value with the ticket. Obsoletes RFC 8446.
- IAB Workshop on Accelerating the Deployment of Post-Quantum Authentication (iab.org) - the workshop this position paper was submitted to.