{"id":"32e78de7-31b1-4678-8c4d-9f1ab1604ef0","arxiv_id":"2607.29005","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Across 684k consistently reachable domains, PQ-TLS adoption reached 49% by March 2026, almost entirely via X25519MLKEM768 and managed infrastructure, with no measurable latency increase.","lead":"This paper measures post-quantum TLS adoption across a million domains over eight months, finding that nearly half default to one hybrid key exchange (X25519MLKEM768) and that most adoption is driven by a handful of CDNs. It also finds no meaningful latency penalty for PQ-TLS at Internet scale, contrary to earlier experimental expectations.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 'infrastructure-driven transition' conclusion rests on an unvalidated attribution heuristic; a strict-classifier sensitivity check is needed before the 93.92% claim is accepted.","rationale":"The reader's weakest assumption is the TLS-management attribution heuristic in §4.4, and I agree that this is the point where a large error would most directly change the paper's central conclusion. The internal logic of the configuration, latency, and failure-mode analyses is otherwise coherent: the stable-panel definition is clearly stated, the support/default distinction is sensible, and the differential latency methodology controls for network noise. The attribution heuristic, however, is applied to the majority of the panel and is the sole basis for separating infrastructure-mediated adoption from operator migration. It is not obviously wrong; confirmed CDN/cloud provider identification is usually reliable, which is why the appropriate response is a focused sensitivity test rather than rejection. The proposed strict-classifier recomputation would show whether the 93.92% figure and the derived RQ3/RQ5 patterns survive when the speculative 'high fanout' component is removed. Since the reader already assigned CONDITIONAL, this stress-test does not change the verdict.","tokens_in":25792,"tokens_out":15058,"duration_ms":149432,"concrete_test":"Run a sensitivity analysis on the stable panel: redefine 'infra-managed' using only high-confidence evidence (known CDN/cloud IP ranges, provider-specific CNAME/PTR, and AS ownership), and reclassify all domains flagged solely via 'high IP fanout / shared-hosting metadata' as 'unknown'. Recompute the RQ2 share, Figure 3, and the RQ5 provider-balanced comparisons. If the infra-managed share of PQ-TLS defaults remains above roughly 90%, the concern is resolved; if it drops below roughly 70% or the RQ5 legacy-feature gaps shrink, the central narrative depends on the unvalidated heuristic. Optionally, hand-label 300 domains per attribution class from provider documentation to produce a confusion matrix.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The most load-bearing unvalidated component is the TLS-management attribution heuristic in §4.4. It is applied to 91% of the stable panel and directly produces the headline RQ2 result: 93.92% of PQ-TLS defaults are classified as infrastructure-provider managed, with only 4.58% owner-managed. It also conditions the RQ3 finding that policy timelines do not matter once infrastructure is controlled, and the RQ5 finding that provider-managed PQ-TLS retains more legacy features. The heuristic labels as infra-managed not only confirmed CDN/cloud matches (IP ranges, CNAME, PTR, HTTP metadata, AS ownership) but also 'characteristics of shared hosting such as high IP fanout.' That extension is where error is likely: a domain on shared hosting may have TLS configured by the owner via a control panel, or auto-provisioned by the host, and the paper reports no error rate, no ground-truth set, and no inter-rater agreement. Since Cloudflare and Fastly are identified directly by IP ranges and have enabled PQ by default, the high infra share is partly by construction; the claim that owner-managed migration is negligible depends on the less reliable part of the classifier. If misclassification is correlated with PQ status, the 93.92% figure could materially overstate the infrastructure-mediation story.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents the first longitudinal, vendor-agnostic measurement study of post-quantum TLS (PQ-TLS) on the public HTTPS ecosystem after NIST standardization. The authors scan roughly one million domains from 11 geographically distributed cloud vantage points in three rounds (July 2025, November 2025, March 2026), building a stable panel of 684,494 domains. They report that default PQ-TLS negotiation converges on the single hybrid construction X25519MLKEM768, reaching 49.22% of the stable panel by March 2026; that 93.92% of PQ-TLS defaults are attributed to infrastructure-provider-managed TLS, with Cloudflare and Fastly together accounting for about 70%; that national transition timelines and sectoral priorities show limited correspondence with observed deployment; that hybrid PQ key exchange introduces no measurable latency increase in their measurements; and that PQ-TLS is frequently deployed alongside legacy TLS features. The paper also surveys PQC transition policies in eight jurisdictions and compares findings across DomCop, Tranco, and CrUX domain lists.","tokens_in":26071,"tokens_out":6398,"duration_ms":64670,"significance":"If the measurement and attribution concerns are adequately addressed, this would be a valuable and timely empirical contribution. The scale (2 billion handshakes, 1M domains, 11 vantage points, three rounds) and the paired differential-latency design are strengths. The paper's central observations — de facto convergence on X25519MLKEM768, infrastructure-mediated deployment, and negligible observed latency overhead — are policy-relevant and would be a useful benchmark for PQC transition planning. The robustness check across multiple top-domain lists (Appendix C) and the detailed protocol-security labeling criteria (Appendix E) support reproducibility. However, the headline 'infrastructure-driven transition' claim rests on an unvalidated attribution heuristic, and the stable panel excludes nearly one third of scanned domains; both issues must be addressed before the main findings can be considered established.","major_comments":[{"comment":"The TLS-management attribution heuristic is load-bearing for RQ2, RQ3, and RQ5. It labels domains as 'potentially infrastructure provider managed' not only on direct IP/CNAME/PTR/AS matches but also on 'characteristics of shared hosting such as high IP fanout and known infrastructure-linked metadata.' The paper reports no ground-truth validation, precision/recall, or inter-rater agreement. A domain on shared hosting can have TLS configured by the domain owner through a control panel, so this extension may misclassify owner-managed deployments as infrastructure-managed. Since misclassification is plausibly correlated with PQ status, the 93.92% figure in §5.2 may materially overstate the infrastructure-mediation claim. Please provide a sensitivity analysis (e.g., reclassify shared-hosting/unknown labels to owner-managed and show how RQ2, Fig. 1, Fig. 3, and RQ5 results change) and validate","section":"§4.4, §5.2"},{"comment":"The stable panel is 684,494 of 1,000,000 domains (68.44%); the remaining 315,506 domains are excluded because they fail TLS 1.3 handshakes from at least one vantage point or round. PQ-TLS is observable only in TLS 1.3-capable endpoints, so the panel is likely biased toward modern infrastructure and against owner-managed and government domains, which the paper concludes are lagging. The statement that 'nearly half of the stable panel defaults to PQ-TLS' is conditional on this panel, not representative of the Top 1M as a whole. Please report adoption over all March 2026 successful scans (Table 4, n = 714,067) alongside the stable-panel figures, and provide a bounds analysis for excluded domains (e.g., using TLS 1.2 reachability and provider attribution to estimate an upper bound on PQ-TLS adoption across the full list).","section":"§5, Table 2"},{"comment":"Table 5 reports DomCop X25519MLKEM768 default of 49.74% for March 2026, while Table 2 gives 49.22% for the stable panel in the same month. The difference (about 0.52 percentage points, or roughly 18,000 domains) is not explained. If Table 5 uses all successful scans while Table 2 uses the stable panel, this should be stated explicitly and the two denominators reconciled. Since the abstract and conclusion rely on 'nearly half' of domains adopting PQ-TLS, the reader needs a single, clearly defined denominator for the headline adoption rate.","section":"Appendix C, Table 5 vs Table 2"},{"comment":"The claim that policy timelines show 'no clear evidence' of correspondence with deployment is based on mean adoption rates (32.4% vs 45.7%) and within-Cloudflare comparisons, but no confidence intervals, hypothesis tests, or provider-composition controls are reported. The apparent reversal could be driven by differences in CDN market share across ccTLD samples or by other confounders. Please provide a small regression or stratified table with confidence intervals; if the sample size is insufficient for inference, state that limitation explicitly. This is needed to support the strong RQ3 conclusion that infrastructure composition, rather than policy, explains cross-country differences.","section":"§5.3.4, Fig. 3"}],"minor_comments":[{"comment":"Typo: 'E-Commerece' should be 'E-Commerce'.","section":"Fig. 3"},{"comment":"The caption reports ΔT p90 = 14 ms and 'over 90% of domains experience a latency difference of at most 14 ms,' while the text reports absolute handshake-time 90th-percentile difference of 5 ms. Please use consistent terminology (delta vs absolute) and clarify which quantity each statement refers to.","section":"§5.4.1, Fig. 4"},{"comment":"The legend symbols (filled/hollow circles, squares, triangles) appear to be missing or mis-rendered in the table. Please ensure the notation is visible in the final version.","section":"Table 1"},{"comment":"References [66] and [67] appear to be the same CoNEXT 2023 paper with the same author list; duplicate entries should be merged.","section":"References"},{"comment":"'compression mechanisms, which corresponds to a higher prevalence...' is grammatically awkward. Also, the phrase 'potentially infrastructure provider managed' in §4.4 is later used as the categorical 'infrastructure provider managed' in §5.2; please maintain the probabilistic qualifier throughout the results discussion.","section":"§5.5.1"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First longitudinal, vendor-agnostic picture of PQ-TLS after NIST standardization, and it earns its place. The scan design is careful: differential latency pairs, multiple rounds, 11 vantage points, robustness checks against Tranco and CrUX. The main findings — near-total convergence on X25519MLKEM768, almost no measurable latency penalty, and adoption concentrated in Cloudflare and Fastly — are plausible and useful. I'd trust the configuration and latency numbers more than the attribution numbers.\n\nThe soft spot is the TLS-management attribution heuristic in §4.4. It is applied to 91% of the stable panel and drives the RQ2/RQ3/RQ5 conclusions, but it has no ground-truth validation, no error rates, and extends 'infra-managed' to shared-hosting signals that could go either way. That makes the 93.92% infrastructure-mediated figure less solid than the paper's tone suggests. A sensitivity analysis with a stricter classifier would settle it. Also minor: the stable panel drops 31.55% of domains (connectivity/TLS 1.3 failures), so the longitudinal claims are about reachable, modern endpoints. And there is a small numeric mismatch between Table 2's 49.22% and Appendix C's 49.74% for DomCop default; likely definitional but should be reconciled.\n\nNo circularity issues: this is measurement, not model fitting. The policy survey is thin but clearly labeled as a cross-section, and the conclusion that policy timelines don't predict deployment is supported by the infrastructure-mediation analysis.\n\nWould I send it out? Yes — a competent referee can handle the attribution question. The paper should release code and data; that would also let someone test the classifier.","headline":"A solid, useful measurement paper on PQ-TLS deployment; the infrastructure-attribution heuristic is the one thing I'd want validated before leaning on the headline numbers.","tokens_in":26544,"tokens_out":1716,"would_cite":true,"duration_ms":17658,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper measures post-quantum TLS across the public Internet and finds that despite divergent policy guidance, deployment has converged on a single hybrid construction, is driven almost entirely by managed CDN platforms, and adds no mean","keywords":["post-quantum cryptography","TLS","PQ-TLS deployment","Internet measurement","hybrid key exchange","ML-KEM","X25519MLKEM768","policy alignment"],"falsifier":"A ground-truth audit of a random sample of domains the heuristic labels 'potentially infrastructure provider managed'—for example, asking the operators of those domains or consulting platform configuration documentation—that found substantial misclassification would directly overturn the central 93.92% infrastructure-driven adoption figure.","tokens_in":1604,"feed_emoji":"🔐","tokens_out":1774,"duration_ms":54836,"temperature":0.7,"pith_summary":"The paper establishes the first longitudinal, vendor-agnostic picture of how post-quantum cryptography is actually being deployed in TLS after NIST standardization, based on more than two billion handshakes to a million domains from eleven global vantage points. It finds that, despite widely varying national policy recommendations, operational PQ-TLS has converged on a single hybrid key exchange, X25519MLKEM768, which nearly half (49.22%) of a stable panel of 684,494 domains defaults to by March 2026. The paper shows this adoption is overwhelmingly driven by a few managed infrastructure providers, with Cloudflare and Fastly together accounting for nearly 70%, while owner-managed and government domains remain mostly classical. National timelines and sectoral priorities show little correspondence with observed deployment. It also finds that PQ-TLS introduces no meaningful handshake latency increase in Internet settings, although it is often deployed alongside legacy TLS configurations. The sympathetic reader cares because these results suggest that the post-quantum transition is being shaped more by platform defaults than by policy, and that aggregate adoption statistics can overstate security modernization.","feed_headline":"Nearly half of top domains now default to post-quantum TLS","feed_subtitle":"Two CDNs drive nearly 70% of the shift; latency is flat; policy timelines don't predict who migrates.","key_machinery":"The central object is the TLS 1.3 handshake negotiation itself, observed through a custom scanning client that advertises NIST-standardized PQC algorithms; the paper isolates the hybrid key exchange group X25519MLKEM768 as the single construction that dominates real-world defaults. Two mechanisms carry the argument: a differential measurement design that performs matched PQ and classical baseline handshake pairs spaced four hours apart, allowing per-domain latency deltas to be attributed to the PQ component; and a TLS management attribution heuristic that classifies each domain as 'potentially infrastructure provider managed', 'potentially owner managed', or 'unknown' by layering IP-range ma","core_discovery":"The paper presents the first longitudinal, vendor-agnostic measurement study of publicly deployed post-quantum TLS after NIST standardization. By actively probing over one million domains with a custom TLS 1.3 client from 11 globally distributed vantage points in three rounds (July 2025, November 2025, March 2026), it observes that operational PQ-TLS has effectively standardized on a single hybrid construction, X25519MLKEM768: every domain that negotiates PQ key exchange by default uses this group, and it rises from 31.26% of the stable panel to 49.22% over the study period. The authors find that 93.92% of PQ-TLS deployments come from infrastructure-provider-managed configurations, with Clou","pith_inferences":["A natural testable extension: if X25519MLKEM768 must be replaced (due to a security break or policy mandate), the infrastructure-mediated model predicts the fix would propagate quickly across most domains, while the long tail of owner-managed domains would remain stuck on whatever default their software ships with.","The paper's central 'infrastructure-mediated transition' narrative is only as strong as its attribution heuristic; a public validation study reporting error rates and inter-rater agreement for that classifier would be the most direct next step.","The speed of PQ-TLS adoption (47% in about 15 months) mirrors the TLS 1.3 rollout but is even faster due to the same platform-driven dynamics; if that analogy holds, PQ-TLS may plateau short of universal coverage because of long-tail inertia, leaving a persistent quantum-recording risk.","Since all latency measurements come from well-provisioned cloud vantage points, the 'no meaningful latency increase' claim may not generalize to constrained residential or mobile last-mile networks; replicated measurements from those environments would test that boundary."],"forward_implications":["If current patterns hold, the post-quantum transition on the public web will be defined by the configuration choices of a handful of CDN platforms, not by national mandates or sectoral priorities.","The absence of a measurable latency penalty suggests that performance concerns should not delay PQ-TLS rollout; the only consistent operational cost is a ~1.1 KB increase in handshake message size per direction.","Because PQ-TLS is layered onto existing configurations, aggregate adoption numbers can overstate security progress; many PQ-enabled domains still support legacy TLS versions and deprecated ciphers.","Owner-managed and government domains lag well behind infrastructure-managed ones, implying that near-term policy deadlines (2030-2031) are unlikely to be met without targeted deployment support.","Alternative hybrid constructions (e.g., secp256r1MLKEM768, secp384r1MLKEM1024) appear only as non-default capabilities, indicating that the ecosystem is effectively dependent on a single hybrid construction."],"fun_headline_variants":["Nearly half of top domains now default to post-quantum TLS","One hybrid key exchange dominates post-quantum TLS","CDNs drive 94% of post-quantum TLS deployments","No latency penalty for post-quantum TLS in practice","Policy timelines don't predict who migrates to PQ-TLS"],"cache_read_input_tokens":27904,"weakest_assumption_plain":"The claim that nearly all observable PQ-TLS adoption is infrastructure-driven rests on a heuristic that guesses, from IP ranges, DNS records, HTTP metadata, and AS ownership, whether a domain's TLS configuration is managed by its hosting platform or by the domain owner—a guess applied to 91% of the stable panel without any reported ground-truth validation or error rates.","fun_headline_variants_meta":{"raw":{"variants":["Nearly half of top domains now default to post-quantum TLS","One hybrid key exchange dominates post-quantum TLS","CDNs drive 94% of post-quantum TLS deployments","No latency penalty for post-quantum TLS in practice","Policy timelines don't predict who migrates to PQ-TLS"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000655,"raw_usage":{"total_tokens":2853,"prompt_tokens":773,"completion_tokens":2080,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":517,"completion_tokens_details":{"reasoning_tokens":2009}},"tokens_in":517,"tokens_out":2080,"duration_ms":16487,"temperature":1.0,"reasoning_tokens":2009,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T15:32:35.822881+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A ground-truth audit of a random sample of domains the heuristic labels 'potentially infrastructure provider managed'—for example, asking the operators of those domains or consulting platform configuration documentation—that found substantial misclassification would directly overturn the central 93.92% infrastructure-driven adoption figure.","supporting_citations":[],"review_version":1}