What must a resumed TLS connection re-check?
TLS 1.2 required a server to refuse a resumption whose name had changed. TLS 1.3 removed that rule and never replaced it. Post-quantum makes the gap expensive.
What this is
A position paper submitted to the IAB Workshop on Accelerating the Deployment of Post-Quantum Authentication. It has not been accepted, reviewed or endorsed by any standards body, and it is not a standard. It is published so the argument and its evidence can be checked.
- Status
- Submitted 28 August 2026. Not accepted, not endorsed, not a standard.
- Venue
- IAB workshop, Prague, 11 to 12 October 2026
- Proposes
- One normative rule on the decision, with four ways to satisfy it
- Protocol change
- None required
- Evidence
- 11 CVE identifiers, 8 products, 2014 to 2026, plus live reproductions
- Suggested follow-up
- TLS working group, or UTA if judged deployment guidance
The proposed rule
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.
The short version
A full TLS handshake sends a certificate chain and validates it. A resumed connection sends none of that and carries the earlier verdict forward. Nothing in TLS 1.3 tells the server what it must re-establish before relying on that verdict, so operators who need client certificates take the only safe answer available and stop resuming. Post-quantum turns that from a 3.5 kB annoyance into a 29 kB one, plus a round trip.
The gap, in the specification's own words
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: "there is no need for the server to associate an SNI value with the ticket." The one certificate-scope rule that remains 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 an oversight anyone can point at. It is an absence, and an absence produces a different answer per implementation rather than one wrong answer.
What it costs, and why post-quantum changes it
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 no longer fits in the first ten packets and the server has to stop and wait. A resumed connection sends no certificate at all.
| 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: almost everyone already banks it, because 94.8% of reachable TLS domains issue a session ticket. The mutual-TLS row is what the rule would actually buy, because that is the population currently unable to resume safely.
Why the small population is the point
Four parties have switched resumption off under mutual TLS, network-wide. They did not do it carelessly. They did it because nothing says what a resumed connection must re-establish, so stopping was the only safe answer available to them. Every operator who deploys post-quantum authentication under mutual TLS meets the same absence and has the same answer available.
One vendor has now done this 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 status 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. That is the difference between a patch and a specification.
What we are not claiming
- This is not accepted work. It is a submission. It has not been reviewed, endorsed, or adopted by the IAB, the IETF, or anyone else.
- The mutual-TLS population has never been measured globally. We report the per-connection saving for deployments that use client certificates, not a claim about how many there are.
- Exploitation is not what is expensive here. The internet-scale scan that found this class classified 176 of 4,370 manually reviewed resumptions as vulnerable. The cost being paid today is the retreat, not the breach.
- Most of the vulnerabilities are fixed. nginx, Go and Cloudflare have all shipped fixes. The argument is that each fix is sound and none generalises, because there is nothing to conform to.
The documents
The paper is the submission. Everything else is supporting material, there so the claims can be checked, and none of it needs reading to follow the argument.
- Position paperStart here2 pages · PDFThe submission. Five deployments where a resumed connection replays a verdict it should have re-checked, the byte arithmetic, the specification gap, who has switched resumption off, and the proposed rule.
- Supporting 1: the vulnerabilities12 pages · PDFEleven identifiers across eight pieces of software, 2014 to 2026. The inclusion test that decides what counts, the CVEs deliberately excluded and why, and the provenance for every row.
- Supporting 2: why this needs a definition9 pages · PDFThe reading of RFC 9846, a survey of how nginx, BoringSSL, Go, HAProxy, Envoy and Fastly bind a session today, the adjudication of which of them conform, and the proposed normative text with the provenance of each part.
- Supporting 3: what is specific to post-quantum6 pages · PDFThe byte model constant by constant, with the measurements it rests on, and what Merkle Tree Certificates and KEM-based authentication would and would not change.
- Supporting 4: what conforming saves4 pages · PDFWhat a deployment pushes today against what it would push if it could resume, per connection and at one million users, with the assumptions stated separately so they can be replaced.
- Long-form paper5 pages · PDFA five-page treatment of the same argument. Not part of the submission, which the workshop asked to keep to one or two pages.
- Slides10 pages · PDFTen slides. Not part of the submission; the workshop is discussion, not talks.
The vulnerabilities
The corpus is eleven CVE identifiers across eight pieces of software, spanning September 2014 to February 2026. Twelve rows, because CVE-2025-23419 covers two separate deployments. 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. One is a revocation bypass.
| count | |
|---|---|
| CVE identifiers | 11 |
| Rows (identifiers, split by deployment) | 12 |
| Distinct pieces of software | 8 |
| Outside party gains standing access | 5 |
| Revocation bypass | 1 |
| Span | Sep 2014 to Feb 2026, 11 years and 5 months |
Apache, Envoy and stunnel each shipped their own version of the same thing, independently. curl appears four times. That 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.
What we took out, and why it matters that we say so
A wider "client-certificate or scoping" count was dropped from the corpus during review: it conflated opposite threat models, and a headline number that needs a disclaimer to survive a recount does not belong in a document whose whole claim is that its numbers survive recounting. Supporting document 1 lists every CVE considered and excluded, with the reason.
The tests
Everything is reproduced against current releases rather than cited from an advisory, because an advisory tells you what was true when it was written. Each experiment carries a control: the same test on a full handshake, so a result means the resumption path specifically.
- OpenSSL, server side3.6.3
A resumed session carrying an expired client certificate is accepted. The control full handshake rejects it with "certificate has expired".
Reproduced
- OpenSSL, client side3.6.3
A resumed session past the server certificate's expiry is accepted. The control returns verify code 10.
Reproduced
- nginx, cross-virtual-host scope1.31.4
The CVE-2025-23419 fix holds. A ticket minted at the public virtual host is refused at the mTLS one, with a control replaying it at its own host to prove it was offerable.
Fixed in current code
- Go crypto/tls1.27.0
Re-establishes certificate expiry and trust-anchor membership on resumption, which is more than the roster's one-line summary conveys. Both baselines resumed.
Fixed in current code
- HAProxy3.4.3
Inconclusive. Separate bind lines already isolate the sessions, so this configuration does not exercise what the August 2026 commit series changes.
Inconclusive
- Fourteen public endpoints27 and 28 August 2026
14 of 14 issue a session ticket, 13 of 14 resume, and 11 of 14 already negotiate the post-quantum hybrid group. A silent connection draws a ticket from only 8 of 14, which is why the harness sends one HEAD.
Reproduced
Check it yourself
Every measured figure above is computed from files in these repositories.
- quantakrypto/tls-resumption-tests Every experiment above, the fourteen-host panel, the harness, and the per-host run files each measured figure is computed from. No key material is committed; each directory regenerates its own.
- quantakrypto/pqc-observatory A second, independent implementation measuring key exchange and session resumption daily across a larger public panel, so the two figures the argument leans on hardest can be checked against something other than our own harness.
Has the IETF or the IAB accepted this?
No. It is a position paper submitted to a workshop on 28 August 2026. Workshop submissions are inputs to an agenda, not endorsements, and the workshop itself is explicitly not a venue for converging on an approach. Nothing here is a standard or a recommendation from any standards body.
Is this a vulnerability disclosure?
No. Every vulnerability in the corpus is already public, most are fixed in current releases, and none of the reproductions targets anyone's infrastructure. The argument is not that a specific product is broken; it is that the same question keeps being answered differently because no specification answers it.
Am I affected?
Only if you terminate TLS and use client certificates. Ordinary HTTPS to a public site is not in scope: not resuming there costs a little speed and is entirely safe. The exposure is a server relying on a cached client-certificate verdict for a decision a fresh handshake would decide differently.
How do I check my own deployment?
Mint a session ticket against 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, the verdict crossed a boundary. Only ever do this against infrastructure you operate: replaying a ticket at someone else's host is probing their access control.
Does the rule require a protocol change?
No. It binds the decision rather than the handshake path, and there are four conforming ways to satisfy it: re-establish the condition from the cached session, refuse to resume, defer the decision as Apache does with a 421, or over-approximate by binding the trust configuration and authentication policy into the resumption scope.
References
- S. Hebrok, T. L. Storm, F. M. Cramer, M. Radoy, J. Somorovsky, "STEK Sharing is Not Caring: Bypassing TLS Authentication in Web Servers using Session Tickets", 34th USENIX Security Symposium, August 2025.
- RFC 9846, The Transport Layer Security (TLS) Protocol Version 1.3, July 2026. Sections 4.3.11 and 4.7.1.
- RFC 6066, TLS Extensions: Extension Definitions, January 2011. Section 3.
- RFC 9190, EAP-TLS 1.3. Section 5.7, the closest thing in a published RFC to the rule proposed here.
- Cloudflare, "Resolving a Mutual TLS session resumption vulnerability", 7 February 2025.
- draft-ietf-plants-merkle-tree-certs-05, 6 July 2026.
Measuring your own posture is the same problem, one deployment at a time
The tooling behind this paper is the tooling we run for clients: reproducible tests against current releases, and a measurement you can check rather than a report you have to trust.