Network Impact of Post-Quantum Certificate Chain sizes on Time to First Byte in TLS Deployments Matthew Chou
arXiv:2604.24869v1 [cs.CR] 27 Apr 2026
1
1 , Phuong Cao
1,2,∗
2
University of Illinois at Urbana-Champaign, National Center for Supercomputing Applications
Abstract—Post-Quantum Cryptography (PQC) is a rapidly growing deployment challenge as cryptographically relevant quantum computers (CRQC) continue to advance, leaving traditional cryptographic algorithms used in X.509 vulnerable to attack. However, PQC introduces significant deployment challenges in real-world networks, with handshake sizes increasing from 5x to over 20x compared to classical algorithms. In this work, we evaluate the time to first byte (TTFB) under CDNfocused TLS conditions to characterize the latency cost of transitioning existing internet infrastructure to quantum-safe certificate schemes. We observe discrete increases in TTFB as certificate chain sizes exceed transport layer data flight limits. To isolate the impact of certificate chains, we evaluate both ECDSA and ML-DSA-based certificate schemes, generating similarly sized certificate chains through controlled addition of certificate extensions. We additionally examine how CDN properties such as session resumption, certificate size optimizations, and geographical distribution reduce latency penalties. To ground our findings in real-world applications, we utilize Zeek-monitored TLS traffic through a High-Performance Computing System (NCSA) with terabyte network connectivity across the nation to quantify realworld session resumption rates. We compare CDN-driven size optimization with Merkle Tree Certificates (MTC) to examine how size reductions allow certificate chains to remain under the flight limit threshold. We find that MTC allows for 2x3x increase in supportable certificate chain size, whereas CDNbased optimizations yield more limited reductions, supporting up to approximately 1.6x certificate chain size increase. These findings reveal a bandwidth-rooted bottleneck in PQC deployment latency, highlighting the critical importance of certificate chain design and optimization strategies for achieving a practical quantum-safe internet infrastructure. Index Terms—Post-Quantum Certificates, Transport Layer Security, Content Delivery Networks, Network Latency
I. I NTRODUCTION Cryptographically relevant quantum computers (CRQCs) are expected to break real-world encryption schemes using Shor’s algorithm, also known as Q-Day [1]. Although quantum computers are still years away from being strong enough to break modern encryption algorithms such as RSA, there remains the threat of attackers who will harvest encrypted data now to be decrypted later when quantum computers become available. This motivates the development of PostQuantum Cryptography (PQC), i.e., algorithms resistant to quantum computing [2]. The National Institute of Standards and Technology is standardizing PQC and developing deployable quantum-resistant algorithms for key exchange/encryption and digital signatures [3]. *Corresponding author: Phuong Cao; Data: https://pmcao.github.io
This work evaluates how certificate chain length directly affects TTFB, specifically using both traditional and PostQuantum-based certificate schemes and artificially inflating their sizes to isolate the network-derived latency. We vary the round-trip time (RTT), the number of intermediate certificates, and the certificate size to further analyze the effects of end-toend delays. We observe that the dominant factor contributing to TTFB is not propagation delay but rather bandwidth limitations and implementation overhead. Our work also proposes using CDN-specific behaviors as well as Merkle Tree Certificates (MTC) [4] to reduce RTT by keeping certificate chain sizes within the flight capacity threshold. However, while these algorithms do protect against quantum adversaries, they have several drawbacks. PQC secures data using mathematically complex problems, such as lattice problems and high-dimensional algebra, thereby substantially increasing the number of bits required for both keys and certificates. Certificate sizes, in particular, increase substantially, ranging from 5x to over 20x depending on the specific scheme used [5], [6]. This negatively impacts Transport Layer Security (TLS) handshakes as packets exceed the Maximum Transmission Unit (MTU), leading to data fragmentation and increased round-trip times (RTT). These directly affect the time to first byte (TTFB), a user-facing performance metric [7]. While the TLS protocol remains consistent across deployment environments, higher latencies affect infrastructure differently. Content Delivery Networks, which are built to minimize latency by serving content from geographically adjacent edge servers, represent a distinct case compared to traditional non-CDN origin-based systems [8]. The increased latency introduced by PQC would significantly affect CDN infrastructure, as these latency-optimized environments handle millions of connections where even small per-connection delay increases can translate into substantial consequences at scale [9]. There have been many studies evaluating PQC in TLS environments on handshake latencies and PQC overhead [10], [11]. However, these works do not isolate the effect of certificate chain sizes on TTFB, nor do they explicitly model transport layer flight limits. We use data from the Zeek measurement tool [12], [13] with NCSA’s database to analyze CDN-specific properties such as session resumption rates, providing realworld conditions for our experiments. Results. Merkle Tree Certificates and CDN chain optimizations allow for certificate chain size increases by ∼2x-3x and
up to ∼1.6x respectively while still keeping certificate chain size within bandwidth control window thresholds. Moreover, session resumption is able to keep certificates under bandwidth limits, with CDNs saving 2x more time to first byte (TTFB) than non-CDNs on average. Our data is grounded in real results with us seeing ∼80%-90% Session Resumption rates for CDNs. We additionally observed CDN session resumption rates are proportinal to TLS 1.3 adoptions rates over our 16 month dataset. Contributions. A summary of our main contributions is as follows: • Analysis of the effect of certificate chain size on TTFB across both ECDSA and ML-DSA-based schemes, allowing for direct evaluation of TLS latencies due to propagation delay. • Comparison of CDN impact on PQC including 1) geographical distribution, 2) certificate optimization, and 3) session resumption. • Evaluation of MTC and CDN optimizations as chain size reduction techniques, comparing their effectiveness in reducing overhead by enabling certificate chains to remain within packet flight limits. • Zeek-monitored TLS traffic of an NCSA to analyze realworld session resumption behavior. Putting this Paper in Perspective. Prior works have studied handshake size on network latency for various PQC certificates. Numerous other works have analyzed CDN optimizations, implemented with real data. However, none of the previous works have directly compared the time to first byte (TTFB), while isolating certificate chain sizes across various CDN and MTC optimizations. II. BACKGROUND This section provides background on modern web security and post-quantum cryptography (PQC). It covers TLS fundamentals, post-quantum cryptography (PQC) basics, relevant certificate types, and key CDN system features. A. Transport Layer Security Overview Transport Layer Security (TLS) is a cryptographic protocol designed to provide secure communication over digital networks. It is most commonly used to securely request and send web traffic through HTTPS and builds a foundation for modern Internet security. TLS ensures confidentiality through the use of key exchanges, digital signatures, and symmetric encryption [7]. TLS establishes a secure channel via a handshake that negotiates the protocol version, cipher suite, certificate, and key exchange method before initiating symmetric encryption. An important step of the handshake relevant to this paper is digital signature verification, in which a server proves its possession of a private key corresponding to the public key in its certificate. Authentication of certificates in TLS is achieved through public key infrastructure (PKI), requiring servers to verify their digital signature. Certificate chains provide a hierarchy of trust for the browser to verify a server’s identity.
There exist three levels of certificates: leaf, intermediate, and root, with each certificate being signed by the level above it and the root certificate serving as a trust anchor that is preinstalled in the client’s device [14]. Cipher Suites and protocol versions provide guidelines on how information is sent and interpreted. There exist two main TLS protocols, namely TLS 1.2 and TLS 1.3, with TLS 1.3 reducing latency, providing additional security, and allowing for easier implementation of PQC. However, not all systems have updated to TLS 1.3 due to legacy architectures and difficulty of deployment [7]. TLS handshake delay stems from multiple sources. Oversized packets exceeding the MTU are segmented, increasing the chance of drops and retransmissions [7] and thus adding time to the handshake. TCP also imposes bandwidth constraints: the initial congestion window (IW) caps first-RTT transmission at 14KB, requiring an extra RTT if exceeded [15], and TCP slow start doubles the window each RTT, creating an effective secondary threshold of 28KB, so transmissions exceeding 42KB total incur yet another RTT. B. Post Quantum Cryptography Fundamentals PQC was developed in response to the threat of cryptographically relevant quantum computers (CRQCs), which could break asymmetric algorithms like RSA and ECDHE via Shor’s algorithm and weaken symmetric and hash functions via Grover’s algorithms [1], [16]. The most pressing current threat is ”harvest now, decrypt later,” where adversaries collect encrypted data today to decrypt once CRQCs mature, potentially within 10–20 years [2], enabling compromise of key exchange and possible signature forgery. In TLS, PQC augments or replaces classical algorithms for key exchange and digital signatures. The most widely adopted algorithms are ML-KEM (CRYSTALS-Kyber) for key exchange and ML-DSA (CRYSTALS-Dilithium) for signatures [17]. Since these algorithms are not yet fully optimized for real-world deployment, hybrid implementations are common, combining PQC with traditional algorithms to maintain security against both quantum and classical adversaries [18]. PQC key exchange, led by ML-KEM, has seen widespread adoption, while PQC certificates remain largely experimental due to their larger sizes and PKI integration requirements. This proves to be a challenge, as the certificate chain structure typically requires 1-2 additional certificates as intermediates, drastically increasing total handshake sizes. These larger certificate sizes make handshakes more sensitive to congestion window limits, and as a result, real-world deployments must balance security and performance, specifically in latencysensitive structures such as CDNs [8]. C. Certificate Schemes in Classical and Post-Quantum TLS Many different types of certificates exist, with more being introduced as the field of PQC grows. This section provides an overview of common certificates and outlines the certificate schemes evaluated in this work. We provide data comparisons in Table I. We ultimately settled on simulating ECDSA, MLDSA, SLH-DSA, and Merkle Trees configurations.
TABLE I: Our Comparison of Certificate Schemes and Structures and Their Impact on TLS [4], [5], [11] Scheme
Type
Cert Size
Chain Size
Handshake Impact
Status
RSA ECDSA ML-DSA FALCON Hybrid ML-DSA
Classical (integer factorization) Classical (elliptic curve) PQC (lattice) PQC (lattice) Hybrid (classical + PQC)
Deployed Widely deployed Emerging Experimental Transition
PQC (hash-based)
High overhead
Experimental
ML-DSA + MTC
Structure (Merkle-based)
Small (∼3–5 KB) Small (∼2–4 KB) Large (∼8–15 KB) Moderate (∼5–10 KB) Very large (∼12–25 KB) Very large (∼60–150 KB) Same as cert size
Low latency Low latency Increased latency Moderate overhead High overhead
SLH-DSA
Research
Structure (Merkle-based)
Reduced size Reduced size
handshake
SLH-DSA + MTC
Small (∼1–2 KB) Small (∼0.5–1.5 KB) Large (∼2.5–4 KB) Moderate (∼1–2 KB) Very large ((∼3.5–6 KB)) Very large (∼20–40 KB) ∼2.5–4 KB (logical), ∼0.7–1.0 KB (proof)a ∼2.5–4 KB (logical), ∼0.7–1.0 KB (proof)a
handshake
Research
Same as cert size
a Assuming a Merkle tree with N ≈ 224 - 228 leaves and SHA-256 hashing, yielding proof sizes as demonstrated in Section II-C3.
h1: "7f3a91c2e8d4b6a0f5ca1b4c7d9e2f8d1a7e…” … h5: "c4d8a1f93e0a5e8f1b9e2a7c4d6f1b3ea0c5…” … h7: "e9b2c7d4a1f8e3c6d4c7d1e9a2b6f3c8d0a5…”
Unoptimized
Root Certificate
Int. 1 Certificate
Int. 2 Certificate
CDN Optimized
Root Certificate
Int. Certificate
Leaf Certificate
Merkle
Leaf Certificate
Merkle Root (Signed by CA)
h7 H(h5+h6)
Leaf Certificate h5 H(h1+h2)
h1 Hash(Leaf)
h6 H(h3+h4)
h2 H(Leaf)
h3 H(Leaf)
Merkle Proof : Hashed with h1 and h5 to derive h7 h4 H(Leaf)
Other Certificates
Fig. 1: Merkle Based Certificate Structure Compared to Traditional X.509 Structure
1) Traditional: The two most common traditional certificates are Rivest–Shamir–Adleman (RSA) [19] and Elliptic Curve Digital Signature Algorithm (ECDSA) [20], with RSA being more common in older systems. RSA uses the mathematical hardness of a prime factoring problem, often containing larger certificate sizes than the elliptic curve-based ECDSA certificates. ECDSA is increasingly preferred with 2-3x smaller certificates, lowering bandwidth and providing faster signatures, but sometimes being incompatible with legacy systems [21]. 2) Post-Quantum: Given that traditional certificates are being broken by Shor’s algorithm, newer certificates require different mathematically hard problems, the most common being lattice or hash-based. The most common digital signatures are Module-Lattice-Based Digital Signature Algorithm (MLDSA), formerly known as CRYSTALS-Dilithium, and Stateless Hash-Based Digital Signature Algorithm (SLH-DSA), which is based on SPHINCS+. NIST has approved both algorithms, with ML-DSA being the primary standard due to its balance of security, performance, and size [22]. SLH-DSA, while standardized, remains mostly impractical due to its huge certificate sizes [5]. There also exist other algorithms, such as Fast Fourier Lattice-based Compact Signatures over NTRU (Falcon) [23], which contain smaller signatures than ML-
DSA. However, Falcon relies on high-precision floating-point arithmetic, making it prone to timing side-channel vulnerabilities that complicate secure real-world implementation. As previously mentioned, hybrid PQC algorithms, which combine pure PQC with traditional algorithms, typically add 1KB to certificate size. In our paper, we focus primarily on ML-DSA due to its balance of signature size and performance, and SLHDSA to act as an edge case to examine the impact of larger certificate sizes. 3) Merkle Trees: For TLS 1.3 X.509 certificates, digital signatures are generated by signing a hash of the message using the signer’s private key and verifying it with the corresponding public key. Each certificate is required to be signed by its issuer, scaling the certificate size with the chain depth, significantly increasing overall handshake size. Merkle Tree Certificate schemes eliminate intermediate certificates by using a Merkle proof to prove that it is within a CA authoritysigned set. We provide a demonstration of the structure of a Merkle Certificate Scheme in Figure 1. It is important to note that Merkle Tree Certificates are a method of proving certificate authenticity and not actual certificates themselves. They differ from the standard X.509 structure, having the CA authority sign the Merkle root, with each leaf containing a Merkle proof that proves its identity through its hash path to
the root, removing the need for certificate chain intermediates. The proof size of an MTC is proportional to the product of the tree height and the hash size [4]. The hash size is 32 bytes when using the SHA-256 algorithm, and the tree height is log2 (N ) where N is the number of leaves. (35) Typically, a CA contains anywhere from 224 - 228 leaves, producing MTC proof sizes of around 700–900 bytes [24]. The MTC leaf size can be expressed as the sum of the original certificate size and the Merkle proof size. While we do not expect much of a decrease in overhead for traditional schemes whose intermediate certificates are not much larger than the proof size, PQC certificates benefit greatly, removing the size complexity introduced by PKI. D. Content Delivery Networks Content Delivery Networks are a system of geographically arranged servers that use caching to reduce content delivery time to users. They implement edge server infrastructure, routing users to the nearest server, focusing on optimizing performance, availability, and scalability to provide users the minimum latency possible. CDNs typically terminate the TLS connection at the edge server, resulting in user connections being between the CDN rather than with the origin server [8], [25]. The CDN controls all aspects of the handshake, making handshake efficiency critical to overall CDN performance. Larger key and certificate sizes pose a particular challenge for CDNs, which are centered around low latencies. The increased handshake sizes are more sensitive to congestion window limits than classical alternatives, where each additional RTT incurred carries significant latency penalties at CDN scale. Even small amounts of packet loss can significantly affect aggregate latency. CDNs utilize various optimizations such as geographical location, certificate chain compression, and session resumption to lower latency for users. 1) Geographical Proximity: RTT, which typically dominates end-to-end latency, is affected by a variety of factors, such as routing inefficiency, network congestion, processing delay, and other overhead. A larger physical distance results in a longer propagation delay, which in turn leads to a higher RTT. Local connections typically exhibit RTTs of 1-10ms, regional connections 10-40ms, continental connections 4090ms, and intercontinental connections 120-200+ms [26].
Fig. 2: Example Visual of Distances
CDNs are strategically positioned so that users are usually within 10-50ms of a CDN node. Due to their geographical proximity to end users, CDNs are expected to significantly reduce end-to-end latency compared to non-CDN deployments. Since TLS handshakes require at least one round trip, any additional round trips that may occur due to bandwidth penalties increase the latency proportionally [27]. Additionally, PQC, which has a larger handshake size and is therefore more prone to packet loss and retransmissions, will benefit from a shorter RTT during its increased retransmissions. 2) Certificate Size Optimizations: CDNs optimize certificate chains by omitting unnecessary intermediates, choosing shorter trust paths, or using a chain based on the client’s root trust CAs. The CDN server is not required to send every intermediate certificate, often sending less if the user already has certificates cached. CDNs also typically maintain multiple pre-configured certificate chains for a domain, targeting different client capabilities (e.g., legacy vs modern browsers), dynamically selecting the shortest compatible chain for each connection [28]. A CDN’s distributed edge architecture allows it to dynamically control which intermediate certificates are served, without being constrained by the fixed configurations typical of origin servers. Although these optimizations are small for lower RTT, they reduce packet loss and provide potential for lowering handshake sizes below window size limits [29]. 3) Session Resumption: Session resumption allows clients to reconnect without requiring a full handshake through the use of session tickets to resume data exchange [38]. These session tickets eliminate the need for certificate chains, certificate verification, handshake signatures, or full key exchange setup, effectively removing PQC overhead [7]. While also present in origin servers, it is much more common in CDNs due to their aggressive optimization tendencies. As a result, certificate size impacts on latency may be additionally reduced for CDN structures. Through optimizations, the effect of certificate size on latency has the potential to be reduced using CDN-based architecture. III. R ELATED W ORKS Post-Quantum deployments with respect to transport security have been widely studied. Particularly, handshake latency and size inflation across PQC-based algorithms in TLS 1.3 have been comprehensively reviewed in works by Sikeridis et al., comparing various certificate schemes under realistic conditions [31], [37]. Subsequent studies have further explored this topic, analyzing key exchanges and authentications showing increases in TLS handshake latencies, specifically measuring how window sizes affect slowdowns [30]. Recent Works. A high-level summary of topics covered by related work is provided in Table II. PQC assessments using OQS show that handshake size inflation, cryptographic computation, and network conditions significantly affect latency [32], [33], with bandwidth and fragmentation dependencies noted across key exchange schemes [30]. Although certificate
TABLE II: Comparison of Prior Research vs. Our Work Feature
Related Work
This Work
Primary Variable
General handshake size and protocol-level overhead. [30], [31]
Network Analysis
Continuous modeling of packet loss and propagation delay. [30], [31] Direct comparison of pure PQC vs. classical algorithms. [32], [33] MTC optimization on PQC certificates and CDN optimizations for classical schemes [4], [28], [34]. Generic TLS 1.3 environments and PQC protocol adoption rates. [35], [36] General internet-wide scanning (e.g., Censys, Zeek). [35], [37]
Isolates certificate chain size as the primary determinant of time to first byte. Identifies discrete transport layer flight limits for PQC (thresholds at 10KB and 40KB). Employs size-matched ECDSA simulations to isolate implementation vs. network overhead. Experimental evaluation of MTC and CDN-specific optimizations for PQC environments. Focuses on CDN vs. Non-CDN performance in latency-sensitive architectures. Utilizes NCSA-monitored TLS traffic to quantify real-world CDN session resumption rates.
Benchmarking Optimization Infrastructure Empirical Grounding
hierarchy work has examined chain configurations and placement under PQC TLS 1.3 [31], a key gap remains in that no prior work isolates certificate chain size as an independent latency contributor. Prior work on transport layer evaluations has examined TCP congestion control, MTU limits, and initial window sizes as determinants of handshake overhead, including how larger handshake sizes can trigger additional round trips due to fragmentation. However, these factors are typically measured in combination, rather than isolating the discrete latency thresholds with respect to the size of the certificate chain under PQC [30], [31]. CDNs have been widely studied for latency-reduction strategies such as session resumption and edge server placement, which reduce overhead by eliminating certificate retransmission and minimizing RTT [39]. Certificate chain size reductions have also been examined as a mitigation strategy [29], though these optimizations are largely limited to traditional schemes with minimal PQC exploration. No existing work directly compares CDN-specific certificate chain optimizations under PQC, nor examines how such optimizations relate to transport layer bandwidth thresholds. MTC reduces certificate transmission by replacing X.509 chains with a single proof, though prior work remains focused on design and implementation rather than empirical evaluation under realistic conditions [34]. Internet-wide tools like Zeek have been used to analyze TLS deployments [37], but lack direct CDN vs. non-CDN comparisons and connections to PQC simulations. Novelty. Unlike previous work, this paper isolates certificate chain size as the primary variable of study, constructing PQC certificate chains of varying sizes and mirroring these sizes in traditional X.509 simulations for comparison. The contrast of the two allows us to identify how latency varies between the two as certificate chain sizes increase. We also analyze and indicate where transport-level packet flight limits occur, noting their discrete increases in TTFB with respect to certificate size. We propose the usage of Merkle Tree Certificates (MTC) and CDN chain size optimizations, namely session resumption and certificate size optimizations, to keep handshake sizes
below packet flight thresholds. We additionally quantify the ranges and savings of staying below the said threshold for our simulated data. IV. O UR CDN F INDINGS We analyze traffic from an NCSA with national traffic data to evaluate real-world TLS deployments and session resumption rates for CDN and non-CDN servers. Our data set comprises Zeek-monitored [12], [13] TLS logs from realworld traffic that include metadata on conducted handshakes, such as protocol version, session reuse indicators, and other certificate-related fields. While the logs contained various data about certificates and handshakes, we mainly analyzed the TLS adoption and session resumption rates. We classified CDNs based on their Autonomous System Number (ASN), using GeoIP’s IP to ASN mapping to associate each entry with an organization [40]. We compared the ASN to a list of known CDN ASNs to label CDN endpoints. Note that our CDN ASN label was strict in order to specifically observe CDN behaviors. We classified our data into 4 groups, with the groups being: 1.) CDN, 2.) Cloud, 3.) Non-CDN, and 4.) unidentified. We intentionally separated them into distinct categories, only comparing CDN and non-CDN cases. Observed Trends. Table III shows that CDNs have a significantly higher TLS 1.3 adoption rate (84.74%) compared to non-CDNs (75.73%), consistent with CDNs’ tendency to prioritize modern, low-latency protocol configurations. More importantly, session resumption rates are much higher for CDNs, with 94.16% of TLS 1.3 connections using session resumption as compared to 46.09% of non-CDNs. Overall, CDNs had an 80.30% resumption rate, whereas non-CDNs only had 35.44%. We note that most modern systems, as determined by their usage of TLS 1.3, use session resumptions with CDNs, and legacy systems most likely do not support session resumption, bringing down the rates. We also provide a measurement of the trend of session resumption since January 2025 until the time of writing this paper, April 2026 using the same NCSA data in Figure 3. The plot supports our conclusion as we see correlation between the TLS 1.3 and overall session resumption rate. We thus see
TABLE III: Session Resumption Rates for CDN and NonCDN Endpoints Metric
CDN
Non-CDN
TLS 1.3 Adoption (%)
84.74
75.73
Session Resumption (TLS 1.3, %) Session Resumption (All, %)
94.16 80.30
46.09 35.44
Data collected over a 24-hour snapshot from an NCSA. (Apr. 14 2026)
Fig. 3: Session Resumption and TLS 1.3 Rates from 16 months of NCSA data. that as TLS 1.3 continues to become more prevalent, session resumption rates will likely also rise. However, we have to note several limitations of our setup. First, ASN-based classification is not fully accurate, as cloud providers can be both CDN or non-CDN, causing possible misclassification. Additionally, Zeek logs only provide metadata rather than full packet captures, which does not allow full visibility into fragmentation, packet loss, or precise timings. More detailed data would allow controlled experiments of TTFB in real settings, allowing for a comparison of TTFB for resumed handshakes. Empirical Insight. Despite limitations, this is the first paper to perform measurements of certificate chain size on TTFB. These results allow us to see real-world applications of session resumption and how CDNs aggressively optimize their connections to reduce handshake overhead. This is particularly important in the context of PQC, where session resumption may allow for reduced latencies of larger certificate chains in realistic deployments.
V. O UR PQC S IMULATIONS T ESTBED This section is focused on isolating and analyzing how latencies vary across different certificate chain schemes and sizes. We compare how Post-Quantum implementations of increased certificate chains compare to similarly sized traditional certificate chains, specifically noting how size increase impacts latency, measuring the time to first byte (TTFB) as our main metric. For our simulations, we use OpenSSL, performing a TLS handshake and HTTP GET request, to determine the time from sending the request until the first byte received. We chose this as our primary metric as it has not been widely studied and it reflects the most realistic real world usage, directly measuring the time until a response. Experimental Setup. For all of our measurements, we ran a simple OpenSSL TLS s server, sending an HTTPS request through that TLS connection. For communication between our client and server, we used two Amazon Web Services EC2 Ohio servers to simulate real network behaviors, keeping both client and server in the same region so as not to introduce too many external variables. To introduce delay into our simulations, we used tc netem, a traffic control network emulator, injecting delay on both the forwards and reverse path. It is important to note for our values, we include time of start up overhead, measuring the full end-to-end execution time rather than just the time corresponding to the raw network data. To emulate varying certificate chains for Post-Quantum as well as traditional infrastructure, we artificially inflated the certificate sizes by adding non-critical certificate extensions so as not to affect certificate verification time, padding the DER encoded length of the certificate. Thus, we were able to solely analyze the network overhead due to increased certificate chain size without affecting certificate verification times. We were able to perform this for Post-Quantum certificates in addition to traditional ones through Open Quantum Safe’s (OQS) open source library. (33) It is important to note that at the time, AWS didn’t support OpenSSL 3.5, which is required for OQS, causing us to run the servers on Docker containers. We compare the inflated traditional certificates to inflated PostQuantum certificates to note whether the difference in TLS stacks had any effect on latencies as certificate chain sizes increased. A. Evaluation of Open Quantum Safe Distinctions
TABLE IV: Comparison of Certificate Component Sizes Across Schemes Scheme
Configuration
Leaf (KB)
Intermediate (KB)
ECDSA
Standard Chain
1.0
2.0
SLH-DSA
Standard Chain MTC Variant
16.6 17.6
32.1 –
ML-DSA
Standard Chain MTC Variant
3.9 4.8
8.0 –
MTC entries omit intermediate values, as the scheme does not utilize intermediate certificates.
We begin our study by comparing the OQS implementation TTFB to a standard TLS 1.3 stack to assess whether the differing TLS stacks cause any disparities. We start with the minimal handshake, measuring the TTFB for both cases. We ran 100 simulations for each case with this setup, computing the mean and standard deviation for each one. The time to first byte was measured by starting a timer, establishing a TCP connection, completing the full TLS handshake, sending an HTTPS request, and stopping the timer after receiving the first byte. We can model the TTFB as follows: TTFB = TTCP + TTLS + Trequest + Tresponse
(1)
Certificate Configuration. To compare only the difference between the PQC and traditional TLS stack, we ran a minimal handshake. We only measured the TTFB of a raw TLS connection without enforcing certificate verification and sending a minimal HTTP request. We carried this out for ML-DSA and Hybrid ML-DSA, using OQS first to run the minimal session, and then padding traditional ECDSA certificate sizes to size match the ML-DSA certificates. We used ML-DSA44 and P256-ML-DSA-44 for our specific PQC certificates and P256 for our specific ECDSA certificate given their widespread usage. We also used the hybrid ML-KEM-768 key. To fully isolate how certificate chain size affects the TTFB, we experimented with having 0, 1, and 2 intermediate certificates, observing how the TTFB grew. Limited Impact of Propagation Delay. We observe that from our results in Table V that OQS has a significantly larger TTFB than our simulated data, with a roughly 50-55ms difference. This difference was likely due to PQC key and certificate generation overhead or the TLS stack difference of OQS. Since the minimal TLS connection produced a handshake of roughly the same size, the difference is likely attributable to the TLS stack itself rather than the certificate chain size. To show this, we graphed the incremental TTFB relative to the number of intermediate certificates added, as shown in Figure 4. We see that as the number of intermediates, and therefore certificate chain sizes increase, Post-Quantum and traditional schemes remain relatively similar in incremental TTFB. As the certificate chain size increases, the increase in TTFB is nearly negligible compared to the total TTFB increase, suggesting that for PQC the TTFB is dominated by implementation rather than actual network propagation. We conclude that under our tested conditions, end-to-end latency is dominated by TLS and protocol differences rather than increased latency due to size inflation. The OQS results for hybrid being an additional ∼4ms cannot be explained by certificate size alone, as hybrid chains are only ∼1 KB larger, and our experiments show minimal TTFB differences between increased certificate-sized schemes. This indicates that the observed increase is most likely due to implementation overhead rather than transmission cost.
The similar incremental delays observed with each additional certificate indicate that the impact of certificate size is largely independent of whether we use inflated ECDSA or MLDSA certificates. These results suggest that our simulations of artificially inflated certificates are sufficiently representative of the effects of modeling TTFB for certificate chains increase. Our results also indicate that TTFB is not primarily driven by propogation delay in OQS systems, implying in real world deployments, latency is instead largely influenced by overhead from differences in implementation. B. RTT Impact on TTFB Across Varying Certificate Schemes In this section, we aim to compare how TTFB is affected by varying certificate chain sizes for different RTTs. We not only use the RTTs to analyze the effect of transmission delays, but to also mimic differing geographic distances. We use the same setup as described in Section V, again running 100 simulations for each case, measuring mean and standard deviations. However, for this evaluation, we introduce delay into our simulations by injecting a 2-way RTT. In order to further explore more realistic conditions, we opted to use a full TLS handshake with certificate verification along with the HTTP request. In addition to our varying certificates, we include a session resumption case for each certificate scheme, where we measure the TTFB using session tickets rather than a full handshake. For the resumed session, we first ran a full TLS handshake to establish the session and then measured the subsequent connections of that session. To examine how TTFB changed with varying certificate chain sizes, we used chain sizes corresponding to real certificate schemes, with chain size varying as a function of the cryptographic scheme. It is important to note that we didn’t implement the actual cryptographic protocols or Merkle Tree structure, only artificially simulating their sizes by padding with certificate extensions. Additionally, we only used 1 intermediate to not introduce too many variables. For choosing the size of certificates, we refer to NIST standards, specifically looking at ML-DSA-44 and SLHDSA-192s. (34)(35) ML-DSA-44 serves as a representative TABLE V: Comparison of TTFB Between Classical SizeMatched Simulations and PQC (OQS) Scheme
ML-DSA
Hybrid ML-DSA
Fig. 4: Minimal OQS vs TLS implementations
Certificate Chain
Simulated (ms)
OQS (ms)
Leaf (3.9 KB) Leaf + 1 Int. (7.9 KB) Leaf + 2 Ints. (11.9 KB)
5.46 ± 0.22 6.11 ± 0.18
56.81 ± 0.72 57.26 ± 0.72
6.85 ± 0.20
57.48 ± 0.56
Leaf (4.8 KB) Leaf + 1 Int. (9.5 KB) Leaf + 2 Ints. (14.3 KB)
5.47 ± 0.16 6.16 ± 0.16
60.79 ± 1.12 62.01 ± 0.78
6.80 ± 0.22
63.03 ± 0.72
While increasing the number of intermediates impacts ECDSA sizematched certificates, propagation delay effects are limited in the OQS implementation.
TABLE VI: Time to First Byte Across Round Trip Times for Different Certificate Schemes (ECDSA Based) Certificate Scheme
No RTT
10 ms
50 ms
100 ms
200 ms
ECDSA X.509 ML-DSA SLH-DSA MTC + ML-DSA MTC + SLH-DSA
8.06 ± 0.31 7.98 ± 0.37 8.29 ± 0.23 7.47 ± 0.28 7.73 ± 0.34
28.71 ± 0.17 28.88 ± 1.65 39.20 ± 0.20 28.28 ± 0.18 40.03 ± 0.90
109.00 ± 1.18 108.77 ± 0.19 159.41 ± 0.32 108.96 ± 0.95 158.77 ± 0.18
208.84 ± 0.20 208.80 ± 0.22 309.41 ± 0.34 208.37 ± 0.16 309.20 ± 1.38
409.10 ± 1.80 408.83 ± 0.25 609.45 ± 0.57 408.63 ± 1.28 608.84 ± 0.24
Session Resumption
7.01 ± 0.14
27.39 ± 0.15
107.49 ± 0.15
207.60 ± 1.00
407.63 ± 1.01
Note: Each entry is the TTFB
TABLE VII: Time to First Byte Across Round Trip Times for Different Certificate Schemes (ML-DSA Based) Certificate Scheme
No RTT
10 ms
50 ms
100 ms
200 ms
ML-DSA SLH-DSA MTC + ML-DSA MTC + SLH-DSA
331.08 ± 7.53 341.43 ± 47.79 333.04 ± 24.55 328.96 ± 7.35
381.50 ± 38.93 385.37 ± 8.54 370.35 ± 7.46 392.08 ± 78.71
538.21 ± 10.08 594.48 ± 29.44 544.16 ± 72.77 591.42 ± 33.09
748.01 ± 49.55 845.59 ± 8.80 743.22 ± 36.80 849.04 ± 57.45
1155.84 ± 54.33 1357.31 ± 55.95 1157.77 ± 83.97 1351.17 ± 31.35
Session Resumption
340.19 ± 24.35
381.35 ± 23.49
547.51 ± 30.79
740.31 ± 10.39
1152.69 ± 41.05
Note: Each entry is the TTFB (ms)
baseline for post-quantum signature schemes with moderate size overhead, while SLH-DSA-192s was chosen due to its larger certificate size to act as an edge case. The sizes we used are noted in Table IV. Geographical Impact. We ran our experiments for both ECDSA and ML-DSA-based certificates as seen in Table VII and Table VI. We use RTT to approximate the geographical distances as referenced in Figure 2. While we see a strong impact of RTT for our ECDSA-based simulation, with RTT dominating the TTFB, the ML-DSA simulations remain less affected. We still see that ML-DSA simulations are largely influenced by RTT at higher RTTs, but in most cases, and in cases of CDNs, RTT will rarely reach such edge cases. As discussed previously, the large overhead of Post-Quantum Cryptography has a substantial impact on latencies, especially for CDNs. ML-DSA vs. ECDSA. We observe that TTFB values remained relatively similar for ECDSA and all ML-DSA cases, as no significant increases in ms were observed. However, for both SLH-DSA and SLH-DSA + MTC cases, we see that the TTFB increases by a whole RTT. Within the ECDSA and ML-DSA cases and the SLH-DSA cases, we are unable to observe a noticeable difference in TTFB due to the reduction in certificate chain size that MTC would be expected to introduce. This can be explained in Table V, where we note that increases in TTFB due purely to size were on the scale of tenths of microseconds, which we also noted were overshadowed by the latency increases caused by TLS stack implementations. We note much larger standard deviations for our full experiments due to simulating a full connection in these simulations, masking out the latency impacts of increased certificate chain sizes. While we ran a session resumption case for each certificate scheme, we noticed that the data stayed relatively the same across all of our cases. This is consistent with how session
resumption functions since it doesn’t depend on certificates or keys, instead only verifying the session ticket. One limitation of our simulation of session resumption was that the TTFB values reflect end-to-end application response time rather than just TLS handshake latency. Client and server process startup overhead in addition to TCP connection establishment could have caused the session resumption values to be masked by the larger overhead of other components. Bandwidth Flight Windows. The important takeaway of our simulations is the added RTT for the SLH-DSA cases increased TTFB by up to 1.5x for extreme cases. While transmission delay due to size caused increased TTFBs as we saw in Figure 4, it doesn’t cause the addition of a full RTT. The most likely explanation for this is that there are bandwidth limitations on the network, or more specifically, packet transmission windows, which limit how much data can be ”in flight” at once. From our data, we observe that ML-DSA and ECDSA are small enough to fit within one flight of data, whereas SLH-DSA crosses the flight boundary ”threshold”. Since the TTFB is dominated by mostly non-network-related latencies, ML-DSA is small enough so that it has similar overhead due to size as traditional X.509 certificates. We provide a figure demonstrating the extra RTT introduced by SLH-DSA as compared to an ML-DSA certificate in Figure 6. The figure shows a simulated PQC handshake between a California and Ohio EC2 AWS server using only ML-DSA. The SLH-DSA certificate was not included in the transmission, only acting to demonstrate how exceeding the Bandwidth Initial Window adds an RTT. For our OQS simulation, we see that for certificate chain sizes within packet transmission window sizes, certificate size has little to no effect on the TTFB. A point of interest, however, is whether the certificate size optimizations are able to reduce the certificate size under the threshold, fitting in a
Fig. 5: Certificate Chain Size Optimizations allowing for bypassing of bandwidth penalty thresholds TABLE VIII: Optimization Regions Across Certificate Size Thresholds Optimization
Lower Bound (KB)
Upper Bound (KB)
MTC (1 int.)
10–18
40–78
MTC (2 int.)
10–27
40–117
CDN (25%)
10–13
40–53
CDN (40%)
10–17
40–67
single flight of data. We also note session resumptions being able to achieve the same effect, removing multiple RTTs in extreme cases. C. Mitigating Bandwidth Penalty Through Certificate Size Optimizations We analyze the threshold limits discussed in the previous section, noting precisely where they occur and how certificate chain optimizations are able to lower certificate chains under said thresholds. We maintain the same setup as Section V-B, instead opting to vary certificate size more continuously to isolate where extra RTTs are added. We start with a certificate size of 4KB, increasing by 2KB until 80KB. We used 10 trials per data point and ran simulations for ML-DSA and ECDSAbased algorithms for RTTs of 50 and 100ms. We didn’t measure lower RTTs as the OQS implementation obscures any differences they make. We notice a couple fluctuations in Figure 5 for the values of ML-DSA-based certificates, largely due to network variability being amplified by the RTT. We see our RTT spikes occur at relatively the same certificate chain sizes for ECDSA and ML-DSA, being around 10KB and 40KB. We also observe that RTT doesn’t affect where thresholds occur, only affecting the TTFB. Optimization Heuristics. We approximate the certificate + 1 KB chain savings of Merkle Tree structures as ChainSize 2 for 1 intermediate and ChainSize + 1 KB for 2 intermediates. 3
Fig. 6: Our Sample ML-DSA Handshake Between Ohio and California EC2 Servers Our MTC size were derived from the underlying Merkle Tree structure as demonstrated in Section II-C3 rather than arbitrary assumptions. As a result, while we are unable to directly implement MTC, the estimated certificate sizes remain a realistic approximation of network behavior even without full implementation. We are unable to directly simulate CDN chain optimizations, approximating them according to several studies that claim chain sizes can be reduced by up to 40-50% [41], [42]. While we are unsure whether chain optimizations are applicable to PQC, we evaluate their potential impact on TTFB. Thus, we model savings as (ChainSize) ∗ 0.75 for moderate reduction and (ChainSize) ∗ 0.60 for more aggressive optimizations. MTC and CDN Savings. We provide the ranges in which MTC and CDN optimizations are able to lower the certificate chain size enough to be under the BDP threshold for our simulated setup in Figure 5, providing our exact values in Table VIII. Within our simulation data, MTC optimizations enable certificate chains with one intermediate, ranging from 10–18 KB and 40–78 KB, to avoid bandwidth penalties entirely, while two-intermediate chains remain unaffected up to 10–27 KB and 40–117 KB. For CDN optimizations, we observe smaller ranges with chain size extensions from 10 to 1317KB and 40 to 53-67KB. We see that for one intermediate, MTC allows for nearly double the size of certificate chains, and for two intermediates, it allows for nearly triple. Note that CDN optimizations that we approximate remain unaffected by intermediate count. We see that CDN optimizations allow for a 130% to 167% increase in certificate chain sizes according to our assumptions. Session Resumption Savings. We also demonstrate pos-
Fig. 7: Average savings of ∼2x due to session resumption for CDNs compared to non-CDNs sible savings due to session resumption bypassing overhead from bandwidth penalties in Figure 7. Using the data gathered from Zeek, we multiply the total session resumption rates found in Table III with the savings from Figure 5. We approximate the session resumption TTFB as the TTFB found before the first threshold. For 50ms and 100ms RTTs, we see savings from 40-80ms and 75-155ms, respectively, depending on the certificate chain size, with nearly twice the TTFB savings in CDN compared to non-CDNs. Moreover, as TLS 1.3 adoption continues to increase, we expect to see higher rates of average savings. While the TTFB savings we found are modest compared to the total TTFB, small differences in latency can accumulate at scale, especially for CDNs. D. Limitations We note several limitations in our setup. Although our OQS simulations allowed for experimentation with PQC certificates, we had limited insight into applications across various TLS stacks. Furthermore, we were unable to test real applications of Merkle Tree-configured certificates, nor meaningfully reduce certificate chain sizes with CDN optimizations. Additionally, our measurements were conducted without specifically analyzing packet loss or failure rates, which may affect TTFB in real deployments. The precision of our ASN classification could be improved to provide more accurate results. Despite these limitations, our primary conclusions were unlikely to be affected by these small variations. VI. P OST-Q UANTUM C ERTIFICATE D EPLOYMENT I MPLICATIONS Our results show that the impact of certificate chain size is mainly caused by network-level constraints rather than by transmission overhead alone. In our experiments, we observe clear bandwidth window thresholds, specifically at 10 and 40 KB-sized certificate chains for our Post-Quantum implementation. Crossing these limits introduces an additional RTT to the total TTFB, with the TTFB jumping discretely at these values. This indicates that TTFB remains relatively the same
between threshold ranges, increasing disproportionately across those boundaries. Key Insight 1. End-to-end delay is largely dominated by bandwidth limits and implementation overhead rather than pure packet propagation. In comparing padded ECDSA certificates to their ML-DSA counterparts, we isolated network and implementation effects, allowing us to directly analyze the impact of certificate chain sizes on latency. We saw that the OQS measurements were larger than the traditional implementations of TLS 1.3, indicating that in practical deployments, TTFB is dominated by implementation rather than data transfer overhead. Moreover, by mimicking the behavior of larger geographic distances with an increased RTT, we observe that packet transmission delays negligibly affect TTFB compared to bandwidth packet window restrictions. Key Insight 2. Certificate chain optimizations are able to reduce TTFB by keeping chain size within the bandwidth delay threshold. We compare approximated MTC and CDN optimizations to reduce certificate chain size to be under bandwidth limit penalties. We observe ∼2-3x-sized certificates with MTC and up to ∼1.6x certificate chains with CDNs while still remaining below thresholds. The minimal TTFB impact of larger certificates indicates that implementations can adopt more secure or robust certificate chains without incurring substantial additional overhead. Key Insight 3. NCSA-backed CDN measurements of session resumption provides additional insight for maintaining TTFB despite bandwidth limits. Large TTFBs have consequences exemplified in CDNs, which are centered around low-latency connections. We see that session resumption is also able to bypass the aforementioned boundaries, saving RTT. We integrate our findings with Zeek-monitored NCSA data to compare session resumption rates and savings across CDNs and non CDNs. Additionally, we analyze trends over a yearlong period to demonstrate session resumption rates over time, noting a correlation between TLS 1.3 and overall session resumption rates.
VII. C ONCLUSION AND F UTURE W ORKS We discuss various implementations of Post-Quantum Certificates across various schemes and structures, specifically focusing on certificate chain size impact on TTFB. We note the predominant cause of TTFB increase and present several ways to reduce it, supporting our results with real-world data from an NCSA and discuss implications for future PQC implementation. Some directions of future work are to examine fragmentation and packet loss for varying certificate chain sizes, particularly noting how certificate chain size reductions would benefit latencies in Post-Quantum applications. Another direction of future study is using more detailed data to better model the effects of CDN properties on latency and running certificate chain simulations on real-world CDN infrastructure.
R EFERENCES [1] P. W. Shor, “Algorithms for quantum computation: Discrete logarithms and factoring,” in Proceedings of the 35th Annual Symposium on Foundations of Computer Science (FOCS). IEEE, 1994, pp. 124–134. [2] M. Mosca, “Cybersecurity in an era with quantum computers: Will we be ready?” IEEE Security & Privacy, vol. 16, no. 5, pp. 38–41, 2018. [Online]. Available: https://www.researchgate.net/publication/3282554 49 Cybersecurity in an Era with Quantum Computers Will We B e Ready [3] National Institute of Standards and Technology, “What is post-quantum cryptography?” https://www.nist.gov/cybersecurity-and-privacy/what-p ost-quantum-cryptography, 2024, accessed: 2026-04-23. [4] D. Benjamin, D. O’Brien, B. Westerbaan, L. Valenta, and F. Valsorda, “Merkle tree certificates,” Internet-Draft, IETF PLANTS Working Group, draft-ietf-plants-merkle-tree-certs, 2026, work in progress. Accessed: 2026-04-23. [Online]. Available: https://ietf-plants-wg.gith ub.io/merkle-tree-certs/draft-ietf-plants-merkle-tree-certs.html [5] G. Alagic, D. Apon, D. Cooper, Q. Dang, T. Dang, J. Kelsey, J. Lichtinger, Y.-K. Liu, C. Miller, D. Moody, R. Perlner, A. Robinson, and D. Smith-Tone, “Status report on the third round of the nist post-quantum cryptography standardization process,” National Institute of Standards and Technology, Tech. Rep. NIST IR 8413-upd1, 2022. [Online]. Available: https://csrc.nist.gov/pubs/ir/8413/upd1/final [6] M. Sim et al., “Integrating and benchmarking kpqc in tls/x.509,” Electronics, vol. 14, no. 18, p. 3717, 2025. [Online]. Available: https://www.mdpi.com/2079-9292/14/18/3717 [7] E. Rescorla, “The transport layer security (tls) protocol version 1.3,” RFC 8446, Internet Engineering Task Force (IETF), 2018. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc8446 [8] E. Nygren, R. K. Sitaraman, and J. Sun, “The akamai network: A platform for high-performance internet applications,” ACM SIGOPS Operating Systems Review, vol. 44, no. 3, pp. 2–19, Aug. 2010. [Online]. Available: https://dl.acm.org/doi/10.1145/1842733.1842736 [9] K. Kwiatkowski, N. Sullivan, and B. Westerbaan, “Towards postquantum cryptography in tls,” Cloudflare Blog, Jun. 2019, published June 20, 2019; Accessed: 2026-04-24. [Online]. Available: https: //blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/ [10] J. Barton, W. J. Buchanan, N. Pitropakis, S. Sayeed, and W. Abramson, “Performance analysis of tls for quantum robust cryptography on a constrained device,” arXiv preprint arXiv:1912.12257, 2019, later published in the 8th International Conference on Information Systems Security and Privacy (ICISSP 2022). [Online]. Available: https://arxiv.org/abs/1912.12257 [11] J. W. Bos, C. Costello, M. Naehrig, and D. Stebila, “Post-quantum key exchange for the tls protocol from the ring learning with errors problem,” in 2015 IEEE Symposium on Security and Privacy (SP). IEEE, 2015, pp. 553–570, full version available as IACR Cryptology ePrint Archive, Report 2014/599. [Online]. Available: https://eprint.iacr.org/2014/599.pdf [12] Zeek Project, “base/protocols/ssl/main.zeek,” Zeek Documentation, 2026, accessed: 2026-04-24. [Online]. Available: https://docs.zeek.org/ en/current/scripts/base/protocols/ssl/main.zeek.html [13] V. Paxson, “Bro: A system for detecting network intruders in real-time,” in Proceedings of the 7th USENIX Security Symposium (USENIX Security ’98). San Antonio, Texas, USA: USENIX Association, Jan. 1998. [Online]. Available: https://www.usenix.org/conference/7th-useni x-security-symposium/bro-system-detecting-network-intruders-real-tim e [14] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” IETF, Request for Comments 5280, May 2008. [Online]. Available: https://www.rfc-editor.org/rfc/rfc5280 [15] J. Chu, N. Dukkipati, Y. Cheng, and M. Mathis, “Increasing tcp’s initial window,” RFC 6928, Internet Engineering Task Force (IETF), Apr. 2013. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc6928 [16] L. K. Grover, “A fast quantum mechanical algorithm for database search,” arXiv preprint arXiv:quant-ph/9605043, 1996, originally presented at the 28th Annual ACM Symposium on Theory of Computing (STOC 1996), pp. 212–219. [Online]. Available: https: //arxiv.org/abs/quant-ph/9605043 [17] National Institute of Standards and Technology, “Module-latticebased key-encapsulation mechanism standard,” U.S. Department of
Commerce, Tech. Rep. FIPS 203, Aug. 2024. [Online]. Available: https://csrc.nist.gov/pubs/fips/203/final [18] D. Stebila, S. Fluhrer, and S. Gueron, Nov. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc8017 [19] R. L. Rivest, A. Shamir, and L. Adleman, “A method for obtaining digital signatures and public-key cryptosystems,” Communications of the ACM, vol. 21, no. 2, pp. 120–126, Feb. 1978. [20] Y. Nir, S. Josefsson, and M. Pegourie-Gonnard, “Elliptic curve cryptography (ecc) cipher suites for transport layer security (tls) versions 1.2 and earlier,” RFC 8422, Internet Engineering Task Force (IETF), Aug. 2018. [Online]. Available: https://datatracker.ietf.org/doc /html/rfc8422 [21] Z. Durumeric, J. Kasten, M. Bailey, and J. A. Halderman, “Analysis of the https certificate ecosystem,” in Proceedings of the 2013 Conference on Internet Measurement Conference (IMC). Barcelona, Spain: Association for Computing Machinery, 2013, pp. 291–304. [Online]. Available: https://dl.acm.org/doi/10.1145/2504730.2504755 [22] National Institute of Standards and Technology, “Module-latticebased digital signature standard,” U.S. Department of Commerce, Tech. Rep. FIPS 204, Aug. 2024. [Online]. Available: https: //csrc.nist.gov/pubs/fips/204/final [23] P.-A. Fouque, T. Prest, G. Seiler, W. Whyte, Z. Zhang et al., “Falcon: Fast-fourier lattice-based compact signatures over ntru,” NIST PostQuantum Cryptography Standardization Project, Round 3 Submission, 2020, version 1.2, submitted to the NIST PQC Project. [Online]. Available: https://falcon-sign.info/falcon.pdf [24] B. Westerbaan and F. Valsorda, “Keeping the internet fast and secure: Introducing merkle tree certificates,” Cloudflare Blog, Oct. 2025, published October 28, 2025; Accessed: 2026-04-24. [Online]. Available: https://blog.cloudflare.com/bootstrap-mtc/ [25] M. Pathan and R. Buyya, A Taxonomy and Survey of Content Delivery Networks. Berlin, Heidelberg: Springer, 2008. [Online]. Available: https://link.springer.com/chapter/10.1007/978-3-540-77887-5 2 [26] G. Martı́nez, J. A. Hernández, P. Reviriego, and P. Reinheimer, “Round trip time (rtt) delay in the internet: Analysis and trends,” arXiv preprint arXiv:2301.07788, 2023. [Online]. Available: https: //arxiv.org/abs/2301.07788 [27] I. Grigorik, “Transport layer security (tls),” High Performance Browser Networking, O’Reilly Media, 2013, online chapter from High Performance Browser Networking; Accessed: 2026-04-24. [Online]. Available: https://hpbn.co/transport-layer-security-tls/ [28] M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph, and R. Nicholas, “Internet X.509 Public Key Infrastructure: Certification Path Building,” IETF, Request for Comments 4158, Sep. 2005. [Online]. Available: https://www.rfc-editor.org/rfc/rfc4158 [29] D. Kozlov, “How we ensure cloudflare customers aren’t affected by let’s encrypt’s certificate chain change,” Cloudflare Blog, Apr. 2024. [Online]. Available: https://blog.cloudflare.com/shortening-lets-encrypt -change-of-trust-no-impact-to-cloudflare-customers/ [30] D. Sikeridis, P. Kampanakis, and M. Devetsikiotis, “Assessing the overhead of post-quantum cryptography in tls 1.3 and ssh,” in Proceedings of the 16th International Conference on Emerging Networking EXperiments and Technologies (CoNEXT). Barcelona, Spain: Association for Computing Machinery, Dec. 2020, pp. 149–156. [Online]. Available: https://dl.acm.org/doi/10.1145/3386367.3431305 [31] ——, “Post-quantum authentication in tls 1.3: A performance study,” Cryptology ePrint Archive, Paper 2020/071, 2020, presented at NDSS 2020. [Online]. Available: https://eprint.iacr.org/2020/071 [32] J. A. Montenegro et al., “Towards quantum-resistant transport layer security,” Computer Networks, 2024, evaluates the integration of postquantum and hybrid cryptography into TLS, with emphasis on performance, deployment tradeoffs, and transport-layer effects. [33] ——, “The impact of network conditions on pqc-enabled tls performance,” Computer Networks, 2025, evaluates hybrid and post-quantum TLS performance under realistic network conditions including latency, packet loss, and bandwidth constraints. [34] Chrome Secure Web and Networking Team, “Cultivating a robust and efficient quantum-safe https,” Google Online Security Blog, Feb. 2026, published February 27, 2026; Accessed: 2026-04-24. [Online]. Available: https://security.googleblog.com/2026/02/cultivating-robust-a nd-efficient.html [35] M. Sowa et al., “Pqc network instrument,” IEEE Access, 2024, introduces a measurement framework for analyzing post-quantum cryptography performance across real network environments.
[36] D.-T. Dam, T.-H. Tran, V.-P. Hoang, C.-K. Pham, and T.-T. Hoang, “A survey of post-quantum cryptography: Start of a new race,” Cryptography, vol. 7, no. 3, p. 40, Aug. 2023. [Online]. Available: https://www.mdpi.com/2410-387X/7/3/40 [37] J. Sowa, B. Hoang, A. Yeluru, S. Qie, A. Nikolich, R. Iyer, and P. Cao, “Post-quantum cryptography (pqc) network instrument: Measuring pqc adoption rates and identifying migration pathways,” in 2024 IEEE International Conference on Quantum Computing and Engineering (QCE), vol. 01, 2024, pp. 1835–1846. [38] J. Salowey, H. Zhou, P. Eronen, and H. Tschofenig, “Transport layer security (tls) session resumption without server-side state,” RFC 5077, Internet Engineering Task Force (IETF), Jan. 2008. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc5077 [39] J. Dean and L. A. Barroso, “The tail at scale,” Communications of the ACM, vol. 56, no. 2, pp. 74–80, Feb. 2013. [Online]. Available: https://dl.acm.org/doi/10.1145/2408776.2408794 [40] MaxMind, “Geolite databases and web services,” MaxMind Developer Portal, 2026, accessed: 2026-04-24. [Online]. Available: https: //dev.maxmind.com/geoip/geolite2-free-geolocation-data/ [41] Y. Nir, Y. Sheffer, A. Langley, E. Käsper, and E. Rescorla, “Tls certificate compression,” RFC 8879, Internet Engineering Task Force (IETF), Dec. 2020. [Online]. Available: https://www.rfc-editor.org/info/rfc8879 [42] Let’s Encrypt, “Shortening the let’s encrypt chain of trust,” Let’s Encrypt Blog, Jul. 2023. [Online]. Available: https://letsencrypt.org/20 23/07/10/cross-sign-expiration