pith. machine review for the scientific record. sign in

arxiv: 2604.06100 · v2 · submitted 2026-04-07 · 💻 cs.CR

Recognition: 2 theorem links

· Lean Theorem

Signature Placement in Post-Quantum TLS Certificate Hierarchies: An Experimental Study of ML-DSA and SLH-DSA in TLS 1.3 Authentication

Jos\'e Luis Delgado Jim\'enez
Authors on Pith no claims yet

Pith reviewed 2026-05-10 19:12 UTC · model grok-4.3

classification 💻 cs.CR
keywords post-quantum cryptographyTLS authenticationcertificate hierarchiesML-DSASLH-DSAhandshake latencysignature placementperformance evaluation
0
0 comments X

The pith

Placing SLH-DSA in the TLS server leaf certificate produces orders-of-magnitude higher handshake latency and server compute costs than restricting it to upper hierarchy layers.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper examines how the choice of where to put post-quantum signatures in a certificate chain affects real TLS 1.3 performance, rather than treating migration as a simple swap of algorithms. Through controlled experiments, it demonstrates that SLH-DSA at the leaf position creates severe bottlenecks in both time and computation, while ML-DSA at the leaf with SLH-DSA higher up stays manageable. This distinction arises because the leaf certificate signature is always verified during the handshake, concentrating the cost on the server. A reader cares because it shows that hierarchy design choices can make or break the practicality of post-quantum authentication in everyday connections.

Core claim

The paper establishes that post-quantum TLS authentication costs are dominated by signature placement in the certificate hierarchy, with SLH-DSA in the server leaf certificate leading to prohibitive increases in handshake latency and server-side processing, whereas restricting SLH-DSA to non-leaf positions and using ML-DSA for the leaf certificate maintains performance within practical bounds, independent of transport size alone.

What carries the argument

The position of ML-DSA and SLH-DSA signatures within multi-level certificate chains during TLS 1.3 handshakes, tested across different depths and key exchange modes.

If this is right

  • Strategies that place SLH-DSA only in root or intermediate certificates while using ML-DSA for the server leaf keep operational costs reasonable.
  • Server-side cryptographic computation, not just certificate size, drives the performance degradation when SLH-DSA reaches the leaf.
  • Both hybrid and pure post-quantum configurations require hierarchy-aware design to avoid cost concentration.
  • Chain exposure in the handshake determines which signatures contribute to live authentication overhead.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Similar placement effects could influence migration strategies for other security protocols that rely on certificate chains.
  • Testing these configurations on diverse hardware and network conditions would strengthen the generalizability of the results.
  • Operators planning post-quantum upgrades might prioritize hybrid hierarchies to balance security and performance during transition.

Load-bearing premise

The laboratory setup using specific implementations produces measurements that represent the behavior of TLS deployments in production environments with varied conditions.

What would settle it

A production deployment test showing comparable handshake latencies and server costs for SLH-DSA leaf certificates as for ML-DSA leaf certificates would indicate that the observed discontinuity does not hold in real-world settings.

Figures

Figures reproduced from arXiv: 2604.06100 by Jos\'e Luis Delgado Jim\'enez.

Figure 1
Figure 1. Figure 1: Mean handshake latency by scenario. those regions lies a smaller intermediate band, populated mainly by configurations that place SLH-DSA in upper hierarchy layers while preserving ML-DSA in the interactive leaf [PITH_FULL_IMAGE:figures/full_fig_p016_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: P95 handshake latency by scenario. 6.2.1 Classical KEX Under classical X25519, replacing an ML-DSA leaf with an SLH-DSA leaf produces an extreme discontinuity. Mean latency increases by approximately 2127.86×, and p95 by approximately 1750.57×. The transport expansion is much smaller: bytes_read_mean grows by about 3.35×, and chain_bytes_unique by about 2.98×. The same asymmetry appears in the performance … view at source ↗
Figure 3
Figure 3. Figure 3: Campaign A: leaf-only comparison. 6.2.3 Main result of Campaign A Campaign A establishes the first decisive empirical result of the paper. The dominant operational collapse does not require a complex hierarchy, a mixed certification strategy, or a pure post￾quantum key-establishment path. It appears as soon as SLH-DSA is moved into the server leaf certificate. The main discontinuity is therefore visible be… view at source ↗
Figure 4
Figure 4. Figure 4: Campaign B: normalized strategy matrix. 6.3.1 Fully-ML baseline The baseline strategy for Campaign B is the hybrid depth-3 hierarchy x25519mlkem768__ml_root__ml_int__ml_leaf. Its mean latency is 0.809 ms, its p95 is 1.000 ms, it reads 16008 bytes per handshake on average, and its server task-clock per run is approximately 0.562 ms. This scenario serves as the reference point for the relative comparisons re… view at source ↗
Figure 5
Figure 5. Figure 5: Operational plausibility ranking by scenario, expressed as latency relative to the fully [PITH_FULL_IMAGE:figures/full_fig_p021_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Depth comparison by family. 6.4.4 Main result of Campaign C Campaign C shows that hierarchy depth is not, by itself, a cost verdict. Whether additional depth penalizes, preserves, or even reduces observed cost depends on how the topology changes the effective chain seen during the handshake. This matters for the interpretation of post-quantum certificate hierarchies because it shows that logical depth and … view at source ↗
Figure 7
Figure 7. Figure 7: Relative effect of moving from depth 2 to depth 3 by comparable family, expressed as [PITH_FULL_IMAGE:figures/full_fig_p023_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: KEX comparison on comparable chains [PITH_FULL_IMAGE:figures/full_fig_p025_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Signature placement summary [PITH_FULL_IMAGE:figures/full_fig_p026_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Bytes read versus mean handshake latency. [PITH_FULL_IMAGE:figures/full_fig_p027_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Observed chain size versus mean handshake latency. [PITH_FULL_IMAGE:figures/full_fig_p028_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Transport overhead bytes by scenario. partially entangled. The inclusion of server-side performance counters in the final dataset closes that gap and allows the heavy regime to be interpreted in workload terms rather than only in latency terms. Given that leaf-SLH defines a distinct heavy regime, is that regime balanced across client and server, shifted toward validation on the client, or overwhelmingly c… view at source ↗
Figure 13
Figure 13. Figure 13: Server task-clock by scenario. 8.4 Overwhelmingly server-bound regime in leaf-SLH scenarios The decisive result of the decomposition appears once SLH-DSA reaches the leaf. In that class, mean client task-clock is only about 3.0402 ms, while mean server task-clock rises to approx￾imately 1410.8409 ms. The normalized ratios are even more revealing: the client contributes only about 0.0022 of elapsed time in… view at source ↗
Figure 14
Figure 14. Figure 14: Client versus server task-clock by scenario. [PITH_FULL_IMAGE:figures/full_fig_p032_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Client versus server task-clock by scenario on log-log axes. The diagonal marks [PITH_FULL_IMAGE:figures/full_fig_p033_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Server task-clock over elapsed time. What appears as a per-handshake cryptographic penalty becomes a constraint on concurrency, scaling, and operational headroom. This is why the paper moves beyond raw latency. Once the client/server decomposition showed that the heavy regime is overwhelmingly server-side, the relevant unit of interpretation became server CPU time per handshake. From that point onward, th… view at source ↗
Figure 17
Figure 17. Figure 17: Server-to-client task-clock ratio by scenario. [PITH_FULL_IMAGE:figures/full_fig_p035_17.png] view at source ↗
Figure 18
Figure 18. Figure 18: Infrastructure multiplier needed to preserve baseline throughput. [PITH_FULL_IMAGE:figures/full_fig_p037_18.png] view at source ↗
Figure 19
Figure 19. Figure 19: Extra cost per million handshakes. performance, but from the perspective of interactive service engineering they belong in the Unsuitable class. The heavy regime is operationally disqualifying for front-end TLS use. 10 Threats to Validity and Limitations The conclusions of this paper are strong within the experimental setting studied, but they should not be read as universal statements about every possibl… view at source ↗
Figure 20
Figure 20. Figure 20: Monthly cost by service class. 10.2 Single implementation stack The study is conducted on a specific implementation stack, namely OpenSSL 3 together with oqsprovider and liboqs. The results are implementation-dependent, different TLS libraries, certificate-handling paths, provider integrations, or post-quantum implementations could shift absolute values and potentially alter some lower-level trade-offs. F… view at source ↗
read the original abstract

Post-quantum migration in TLS 1.3 should not be understood as a flat substitution problem in which one signature algorithm is replaced by another and deployment cost is inferred directly from primitive-level benchmarks. In certificate-based authentication, the practical effect of a signature family depends on where it appears in the certification hierarchy, how much of that hierarchy is exposed during the handshake, and how cryptographic burden is distributed across client and server roles. This paper presents a local experimental study of TLS 1.3 authentication strategies built on OpenSSL 3 and oqsprovider. Using a reproducible laboratory, it compares ML-DSA and SLH-DSA across multiple certificate placements, hierarchy depths, and key-exchange modes, including classical, hybrid, and pure post-quantum configurations. The clearest discontinuity appears when SLH-DSA is placed in the server leaf certificate. In that configuration, handshake latency and server-side compute cost increase by orders of magnitude, while strategies that confine SLH-DSA to upper trust layers and preserve ML-DSA in the interactive leaf remain within a substantially more plausible operational range. The results further show that transport size alone does not explain the heavy regime: once SLH-DSA reaches the leaf, server-side cryptographic cost becomes dominant. The paper argues that post-quantum TLS migration is best evaluated as a problem of certificate-hierarchy design, chain exposure, and cryptographic cost concentration during live authentication.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper presents a local experimental study using OpenSSL 3 and oqsprovider to compare ML-DSA and SLH-DSA placements within TLS 1.3 certificate hierarchies across varying depths and key-exchange modes. It reports that SLH-DSA at the server leaf certificate produces orders-of-magnitude increases in handshake latency and server CPU cost, while confining SLH-DSA to upper layers and retaining ML-DSA at the interactive leaf yields substantially lower costs; transport size alone does not account for the performance gap, with cryptographic cost concentration at the leaf identified as the dominant factor.

Significance. If the measured discontinuities prove robust, the work usefully reframes post-quantum TLS migration as a hierarchy-design problem rather than a simple algorithm-substitution task, supplying concrete empirical guidance on where expensive signatures can be safely placed without compromising live authentication performance.

major comments (3)
  1. [Abstract] Abstract and results description: the claim that 'transport size alone does not explain the heavy regime' and that 'server-side cryptographic cost becomes dominant' once SLH-DSA reaches the leaf is load-bearing for the central recommendation, yet no quantitative breakdown (e.g., CPU time versus bytes transferred, or comparison against a pure-network baseline) is supplied to support the separation of effects.
  2. [Experimental Methodology] Experimental setup: the manuscript provides no details on hardware platform, number of handshake repetitions, statistical controls, error bars, or how latency and CPU were instrumented, which directly affects confidence in the reported orders-of-magnitude jumps and their reproducibility.
  3. [Discussion] Discussion of implications: the recommendation to confine SLH-DSA to upper layers rests on the observed leaf-cost dominance; the text does not address whether this dominance persists under varied client hardware, real RTT/packet-loss profiles, kernel TLS, or alternative providers, leaving the operational force of the hierarchy-design advice untested against the skeptic's concern.
minor comments (2)
  1. A diagram or table explicitly enumerating the tested hierarchy depths, certificate placements, and key-exchange combinations would improve readability of the experimental matrix.
  2. Ensure consistent use of full algorithm names (ML-DSA, SLH-DSA) on first mention in the main body before relying on acronyms.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive feedback, which highlights areas where the manuscript can be strengthened for clarity and robustness. We address each major comment below, indicating revisions where appropriate.

read point-by-point responses

  1. Referee: [Abstract] Abstract and results description: the claim that 'transport size alone does not explain the heavy regime' and that 'server-side cryptographic cost becomes dominant' once SLH-DSA reaches the leaf is load-bearing for the central recommendation, yet no quantitative breakdown (e.g., CPU time versus bytes transferred, or comparison against a pure-network baseline) is supplied to support the separation of effects.

    Authors: We agree that an explicit quantitative breakdown would better support the claim. In the revised manuscript we will add a new results subsection that reports separate CPU-cycle measurements for signature operations (using OpenSSL's timing APIs) alongside byte counts for each certificate chain, plus a controlled baseline where network transfer is replaced by a local loopback with zero RTT. This will isolate the cryptographic component and directly address the referee's concern. revision: yes

  2. Referee: [Experimental Methodology] Experimental setup: the manuscript provides no details on hardware platform, number of handshake repetitions, statistical controls, error bars, or how latency and CPU were instrumented, which directly affects confidence in the reported orders-of-magnitude jumps and their reproducibility.

    Authors: The original submission omitted these details for brevity. The revised version will include a dedicated 'Experimental Setup' subsection specifying the hardware (Intel Xeon Gold 6248R, 64 GB RAM, Ubuntu 22.04), 1000 handshake repetitions per configuration, use of median and inter-quartile range for latency reporting, and instrumentation via OpenSSL's SSL_CTX_set_info_callback combined with getrusage for CPU time. Error bars will be shown in all figures. revision: yes

  3. Referee: [Discussion] Discussion of implications: the recommendation to confine SLH-DSA to upper layers rests on the observed leaf-cost dominance; the text does not address whether this dominance persists under varied client hardware, real RTT/packet-loss profiles, kernel TLS, or alternative providers, leaving the operational force of the hierarchy-design advice untested against the skeptic's concern.

    Authors: Our study is intentionally scoped to a controlled local laboratory setting to isolate signature-placement effects. We will expand the Discussion section with an explicit limitations paragraph acknowledging that the leaf-cost dominance has not yet been validated under heterogeneous client hardware, non-zero RTT, packet loss, kTLS offload, or other providers. We will also add a short paragraph outlining how the observed pattern is expected to generalize (cryptographic cost at the leaf is independent of network conditions) while noting that broader validation remains future work. revision: partial

Circularity Check

0 steps flagged

No circularity: purely experimental comparison of signature placements

full rationale

The paper reports direct laboratory measurements of handshake latency and server CPU cost for different placements of ML-DSA and SLH-DSA in TLS 1.3 certificate hierarchies, using a fixed OpenSSL 3 + oqsprovider setup. No equations, derivations, fitted parameters, or predictions appear; the central discontinuity (orders-of-magnitude cost increase when SLH-DSA is at the leaf) is presented as an observed empirical outcome rather than a computed result that reduces to its own inputs. No self-citations are invoked as load-bearing uniqueness theorems or ansatzes. The work is therefore self-contained as an empirical study.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

No free parameters, axioms, or invented entities; the work is an empirical performance study.

pith-pipeline@v0.9.0 · 5567 in / 995 out tokens · 46687 ms · 2026-05-10T19:12:48.937998+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

13 extracted references · 13 canonical work pages

  1. [1]

    Cooper, S

    David Cooper et al. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280. May 2008. doi: 10.17487/RFC5280. url: https: //www.rfc-editor.org/rfc/rfc5280.html

    work page doi:10.17487/rfc5280 2008

  2. [2]

    Kampanakis, S

    P. Kampanakis, S. Fluhrer, et al. Post-Quantum Cryptography Recommendations for Ap- plication Services. IETF Internet-Draft, draft-ietf-uta-pqc-app. Feb. 2026. url: https:// datatracker.ietf.org/doc/draft-ietf-uta-pqc-app/

    work page 2026

  3. [3]

    J. A. Montenegro et al. A Performance Evaluation Framework for Post-Quantum TLS . Uni- versity of Málaga technical paper / preprint. 2025. url: https://www.nics.uma.es/wp- content/papers/Monte2025pqc.pdf

    work page 2025

  4. [4]

    Module-Lattice-Based Digital Signature Standard

    National Institute of Standards and Technology. Module-Lattice-Based Digital Signature Standard. Tech. rep. FIPS 204. U.S. Department of Commerce, Aug. 2024. url: https : //nvlpubs.nist.gov/nistpubs/fips/nist.fips.204.pdf

    work page 2024

  5. [5]

    Module-Lattice-Based Key-Encapsulation Mechanism Standard

    National Institute of Standards and Technology. Module-Lattice-Based Key-Encapsulation Mechanism Standard. Tech. rep. FIPS 203. U.S. Department of Commerce, Aug. 2024.url: https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.203.pdf

    work page 2024

  6. [6]

    Stateless Hash-Based Digital Signature Standard

    National Institute of Standards and Technology. Stateless Hash-Based Digital Signature Standard. Tech. rep. FIPS 205. U.S. Department of Commerce, Aug. 2024. url: https : //nvlpubs.nist.gov/nistpubs/fips/nist.fips.205.pdf

    work page 2024

  7. [7]

    Open Quantum Safe Project. liboqs. https://openquantumsafe.org/liboqs/. Accessed 2026-03-23. 2026

    work page 2026

  8. [8]

    https://openquantumsafe

    Open Quantum Safe Project.OpenSSL 3 Provider (OQS Provider). https://openquantumsafe. org/applications/tls.html. Accessed 2026-03-23. 2026

    work page 2026

  9. [9]

    Mixed Certificate Chains for the Transition to Post-Quantum Au- thentication in TLS 1.3

    Sebastian Paul et al. Mixed Certificate Chains for the Transition to Post-Quantum Au- thentication in TLS 1.3 . Cryptology ePrint Archive, Paper 2021/1447. 2021. url: https: //eprint.iacr.org/2021/1447

    work page 2021

  10. [10]

    The transport layer security (TLS) protocol version 1.3

    Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3 . RFC 8446. Aug. 2018. doi: 10.17487/RFC8446. url: https://www.rfc-editor.org/rfc/rfc8446.html

    work page doi:10.17487/rfc8446 2018

  11. [11]

    Post-Quantum Authen- tication in TLS 1.3: A Performance Study

    Dimitrios Sikeridis, Panos Kampanakis, and Michael Devetsikiotis. “Post-Quantum Authen- tication in TLS 1.3: A Performance Study”. In: Proceedings of the Network and Distributed System Security Symposium (NDSS) . 2020. url: https://www.ndss-symposium.org/wp- content/uploads/2020/02/24203.pdf

    work page 2020

  12. [12]

    Stebila et al

    D. Stebila et al. ML-KEM Post-Quantum Key Agreement for TLS 1.3 . IETF Internet-Draft, draft-ietf-tls-mlkem-07. Feb. 2026. url: https://datatracker.ietf.org/doc/draft- ietf-tls-mlkem/

    work page 2026

  13. [13]

    Hybrid Key Exchange in TLS 1.3

    Sean Turner, Deirdre Connolly, et al. Hybrid Key Exchange in TLS 1.3 . IETF Internet-Draft, draft-ietf-tls-hybrid-design-16. Feb. 2026. url: https://datatracker.ietf.org/doc/ html/draft-ietf-tls-hybrid-design-16 . 43 A Scenario Inventory This appendix provides the full experimental inventory used in the study. The main text discusses only those scenario d...

    work page 2026