Projection · August 22, 2026
The SCTs outweigh the certificates
Swap each embedded SCT signature for SLH-DSA-128s, the conservative hash-based choice for a long-lived log key, and leaf-only ML-DSA migration projects past the initial congestion window for 99.7% of 8,151 measured sites. The overflow is a corollary of 2022 arithmetic. The per-site distribution is what's new.
Two weeks ago I published a comfortable number. Under drop-in ML-DSA-44, leaf-only migration fits TCP’s initial congestion window at 99.7% of the 8,151 real certificate chains in my corpus. Only 0.3% of measured sites exceed it. If the full-chain projection was the bad news, leaf-only was the escape hatch.
That number carries an assumption I stated in the data and did not put in the headline: the Signed Certificate Timestamps stay classical. Change that one assumption, about signatures made with keys that are not yours, and 99.7% flips sides. With SLH-DSA-128s signatures on the SCTs, leaf-only migration projects past the same window for 99.7% of the same sites.
If your post-quantum migration plan has a row that says “leaf certificate only, low risk”, this article is about the bytes that row doesn’t count.
Two or three signatures you never ordered
When your CA issues a certificate, Certificate Transparency requires the certificate to be logged, and each log returns a signed timestamp. Those SCTs ride inside the leaf certificate as an extension. Think notary stamps on a deed: the deed is yours, the stamps are theirs, and the document is not trusted without them. Each stamp is a signature like any other, today typically ECDSA P-256, about 71 bytes. In the corpus, all but 23 of the measured sites carry embedded SCTs, 2 of them at 3,949 sites and 3 at 4,117.
You choose your CA. Your CA chooses which logs it submits to. The logs choose their own keys, and the key decides the signature algorithm and size. So when you plan a “leaf-only” migration, you are choosing the algorithm for one of the signatures your leaf carries. It carries three or four. You don’t hold that pen.
The arithmetic is older than this article
Before the number, the ancestry, because this finding has one. The overflow itself is not new, and I am not claiming it.
Kampanakis and Kallitsis published SPHINCS+-128s authentication totals with SCTs included in 2022: 32.22 KB at one intermediate, rising to 51.10 KB at four, against what they call “the most commonly used TCP initcwnd used today”, about 14.5 KB. Sikeridis, Kampanakis, and Devetsikiotis put the same construction at 36.76 KB the same year, with two SCTs and an OCSP staple. If hash-based signatures everywhere overshoot the window at every chain depth they tabulated, hash-based signatures in the SCTs alone overshooting it is a corollary. Two teams published the parent arithmetic four years ago.
The mixed construction, where the SCT slot gets a different algorithm than the chain, is also published. PQShield presented a per-slot table at IETF 124 with a dedicated Certificate Transparency column: three Falcon-512 SCTs behind an ML-DSA-44 leaf, 9,591 bytes total. Cloudflare has run the same slot arithmetic three times now. From the November 2024 post: “If we use UOV in TLS for the SCTs and root CA, whose public keys are not transmitted when setting up the connection, together with ML-DSA for the others, we’re looking at 7.2kB.” Sikeridis et al. said the quiet part back in 2020: “Falcon, or multivariate schemes would be preferable specifically for SCTs.”
Notice the direction of every published choice. The SCT slot is attractive for small-signature, large-public-key schemes precisely because log public keys never travel in the handshake. Every published mixed table exploits that. This projection runs the same slot arithmetic with the input the published reasoning argues against: the largest signature in FIPS 205, in the slot where the signature is the only thing on the wire.
Every one of those analyses prices a typical chain, parametric by intermediate count or modeled once. None of them says what fraction of the real web lands on which side, or how far past the window a given site goes. The distribution is the contribution. Only that.
The scenario, stated as a scenario
No log operator has announced SLH-DSA SCTs. No source I can find proposes them. This is a priced hypothetical, not a prediction, and the reason it is worth pricing is the shape of the infrastructure. A CT log key lives for years and rotates rarely, and an entire ecosystem leans on it, which is exactly the profile where hash-based signatures get argued for. SLH-DSA is the stateless one, the conservative pick in the FIPS lineup. If a log operator ever reaches for it, the byte consequences should already be on a page somewhere. Now they are.
The signature is 7,856 bytes, measured on local OpenSSL 3.5.5, about 110 times the 71-byte ECDSA signature it replaces. Two of them are 15,712 bytes. The initial congestion window is 14,600. Two log signatures, and the flight is over budget before a single certificate byte is counted.
At the median site, which carries three SCTs, the log signatures total 23,568 bytes inside a leaf-only flight whose median is 30,621. Everything else, certificates, handshake signature, and protocol overhead, fits in the remaining seven kilobytes. The SCTs outweigh the certificates.
What 8,151 real chains say
The corpus is the same one as before: the Tranco top 10,000, captured 2026-08-07, each site’s own chain with its own depth and its own measured SCT count. The projection swaps signature and key bytes per certificate as before, and in this scenario also swaps each embedded SCT signature for SLH-DSA-128s. Chain and handshake signatures stay on ML-DSA.
| Scenario (ML-DSA-44) | Median flight | Past IW10 | Past IW20 |
|---|---|---|---|
| Leaf-only, classical SCTs | 8,506 B | 0.3% | 0.0% |
| Full chain, classical SCTs | 16,810 B | 85.1% | 0.1% |
| Leaf-only, SLH-DSA-128s SCTs | 30,621 B | 99.7% | 51.6% |
| Full chain, SLH-DSA-128s SCTs | 36,427 B | 99.8% | 98.8% |
The leaf-only row is the story. Keep the SCTs classical and nearly everything fits. Send them hash-based and 99.7% does not, and half the web is past a doubled window too. Doubling the window recovers 48% of sites and no more.
The first window’s verdict also went uniform, which is its own tell. In the drop-in projection, the deciding variable was how many intermediates a site carries. Against IW10 in this scenario, leaf-only and full chain land within a tenth of a point of each other, because the dominant term rides in the leaf and everybody’s leaf has two or three SCTs. Depth still separates the two rows at IW20, but at the window that decides the extra round trip, a variable you can influence got displaced by one you cannot.
Who can fix it, and it is not you
There is no server configuration for this. No CA product tier removes it. The knobs live with log operators and the standards bodies, and the standards side is already moving: the PLANTS working group exists to “trim the costs of large post-quantum signatures on PKIs with Certificate Transparency”, and the Merkle Tree Certificates draft counts SCT bytes in its opening motivation: 7,260 bytes of authentication overhead with ML-DSA-44, and that is with a directly-trusted intermediate, the favorable case. Their answer is to restructure the proof rather than shrink the signature. The working group’s standards milestone is dated 2026-11-30, and that document is worth watching.
What you can do is know your exposure before someone else’s key choice sets it. The chain check tool runs this scenario against any public domain, on the site’s real chain and real SCT count, with a window verdict per flight.
Leaf-only was never only the leaf.
Provenance
Measured here (Verified). The corpus captures are from 2026-08-07, Tranco list ZJGPG pinned, 8,152 of the top 10,000 completing a handshake and 8,151 parseable, including each site’s chain depth and embedded SCT count. The SLH-DSA-SHA2-128s signature size (7,856 bytes) and the ML-DSA constants were generated with local OpenSSL 3.5.5 rather than copied from FIPS 205 and 204, and the measurement was re-run 2026-08-22 with the same result. Scripts, captures, and the full dataset are public at pqc-chain-budget (DOI 10.5281/zenodo.21846142).
Projected, not measured (Proposed). Every flight size and window verdict in this article is arithmetic on measured inputs under stated assumptions. No handshake carrying SLH-DSA SCTs was performed, because no log issues them; no log operator has proposed to, and this article does not predict that any will. The 71-byte classical SCT signature is a stated assumption (typical ECDSA P-256), not a per-site measurement.
Cited, not claimed (Reported). The overflow’s ancestry is published work, every source verified against a downloaded full text: Kampanakis and Kallitsis, CSCML 2022 for SPHINCS+ totals with SCTs against the initial window, Sikeridis, Kampanakis, and Devetsikiotis, CoNEXT 2022 for the same at two SCTs plus OCSP, Sikeridis et al., NDSS 2020 for the SCT-slot recommendation, PQShield’s IETF 124 PLANTS deck and Cloudflare’s March 2024, November 2024, and 2025 posts for mixed per-slot tables, the PLANTS charter for the qualitative cost framing, and Ivan Ristic at Red Sift for the most recent modeled-chain arithmetic. A prior-art sweep for SLH-DSA-specific SCT projections ran 2026-08-22 across IACR ePrint, arXiv, OpenAlex full text, Europe PMC, DBLP, USENIX, the IETF Datatracker including all 41 PLANTS documents, 32 MDPI post-quantum papers grepped from their PDFs, and the free tool landscape; ACM and IEEE full text were unreachable and covered by metadata only. The repository’s prior-art file records the full map, including the wording constraints this article is written under.
Things this body of work got wrong along the way. During the sweep, a search summary attributed to a real paper a sentence about SCT overhead that does not exist anywhere in its PDF; the number it quoted is an axis tick on a figure. That is the fourth fabricated or misattributed source this project has caught, and it is why every citation above was verified against a downloaded full text before it was written down.