Pith. sign in

REVIEW 3 major objections 6 minor 43 references

Quantum-Resistant Domain Name System: A Comprehensive System-Level Study

T0 review · 3 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Post-quantum DNS is practical with lattice-based MLKEM and Falcon, while SPHINCS+ and HQC strain bandwidth and CPU.

desk verdict A useful, well-scoped benchmark of PQC for DNSSEC/DoT/DoH; the qualitative bandwidth and CPU findings hold, but the latency claims are tied to a loopback testbed and need stronger evidence. read the letter →

arxiv 2506.19943 v1 pith:H7OZCP5L submitted 2025-06-24 cs.CR cs.NIcs.PF

Juyoul Lee , Sanzida Hoque , Abdullah Aydeger , Engin Zeydan This is my paper · ORCID
classification cs.CRcs.NIcs.PF
keywords post-quantumcryptographyDNSDNSSECDNS-over-TLSDNS-over-HTTPSML-KEMFalconSPHINCS+
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper sets out to determine whether the Domain Name System can be made quantum-resistant without breaking its performance budget. It builds and benchmarks a full DNS stack—DNSSEC, DNS-over-TLS, and DNS-over-HTTPS—under classical, hybrid, and post-quantum-only cryptographic configurations. The central finding is that lattice-based key encapsulation and signatures, specifically MLKEM paired with MLDSA or Falcon, resolve DNS queries at latencies comparable to or better than today's RSA and elliptic-curve settings across all three standardized security levels. Hash-based SPHINCS+ and code-based HQC, by contrast, multiply bandwidth by 2 to 23 times, raise server CPU sharply, and degrade badly under high concurrency. The practical upshot, if these measurements hold in wider deployments, is that operators can migrate DNSSEC, DoT, and DoH to post-quantum cryptography by choosing lattice schemes and by planning mitigations for the bandwidth and denial-of-service risks that larger signatures create.

What carries the argument

The load-bearing object is the PQC-DNS benchmarking framework: a two-phase protocol model consisting of a TLS 1.3 handshake using a post-quantum key encapsulation mechanism and signature, followed by encrypted recursive DNS resolution with optional DNSSEC validation, together with a performance vector S_i(k,s) = (latency, bandwidth, client CPU, server CPU, memory) measured for each cryptographic configuration. The framework runs on a containerized testbed with a patched BIND9 resolver linked to OpenSSL and an open-source post-quantum provider, and it formalizes total resolution cost as a sum of handshake, transport, and DNSSEC terms. That structure lets the authors compare every (KEM, signature) pair under identical conditions across legacy-only, PQC-only, and hybrid deployment classes, which is what allows them to separate algorithm-family effects from protocol-layer effects.

What would settle it

Run the same post-quantum-enabled resolver on a public cloud instance and measure end-to-end DoT latency for MLKEM512 with Falcon512 versus X25519 with RSA2048 under real network round-trip time and background load; if the lattice pair no longer matches or beats the classical pair's latency, or if HQC and SPHINCS+ become competitive because transmission time dominates, the paper's central performance ranking fails. A second check is to push a resolver to 10,000 queries per second with SPHINCS+ signatures and observe whether server CPU exceeds 50 percent with severe latency growth, as the paper predicts.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that the choice of post-quantum primitive, not the protocol, determines whether DNS can go quantum-resistant cheaply. Across DoT and DoH at security levels 1, 3, and 5, MLKEM512/768/1024 combined with MLDSA44/65/87 or Falcon512/1024 matched or beat every legacy FFDHE/ECDSA/RSA combination in end-to-end latency, often landing at 8.8 to 9.3 milliseconds versus 9.2 to 18.7 milliseconds for classical pairs, while raising bandwidth roughly 1.5 to 6 times. HQC-based key encapsulation raised latency to about 19 milliseconds at security level 1 and above 65 milliseconds at level 5, and SPHINCS+ signatures lifted single-query bandwidth to 38 to 87 kilobytes and server CPU to 3 to 3.5 percent. Under 10,000 concurrent queries, MLKEM with Falcon kept latency near 10.8 seconds with server CPU around 9 percent, while SPHINCS+ configurations reached 21 to 23 seconds, server CPU above 54 percent, and total transfer volumes over 380 megabytes per 10,000-query session. The paper also argues that DNSSEC validation itself stays computationally cheap: MLDSA44 and Falcon-512 raise bandwidth but leave resolution latency nearly unchanged relative to RSA or Ed25519, and it identifies downgrade, timing, fragmentation, and DDoS amplification as the main new risks introduced by PQC adoption.

Load-bearing premise

The benchmark assumes that a local containerized testbed on a single desktop CPU, using loopback networking and no competing traffic, represents how real DNS resolvers behave; if real-world network latency, middleboxes, or multi-tenant CPU contention change the balance between cryptographic processing and transmission, the quantitative latency and CPU rankings may not generalize, though the qualitative bandwidth findings likely do.

Editorial extensions

If this is right

  • DoT and DoH resolvers can adopt MLKEM with MLDSA or Falcon without adding noticeable per-query latency, so the first wave of production post-quantum DNS can use existing protocol stacks.
  • SPHINCS+ and HQC should be avoided for latency-sensitive or high-throughput recursive resolvers, because their bandwidth and CPU costs grow with concurrency and security level.
  • DNSSEC zones can move to MLDSA44 or Falcon-512 with only modest bandwidth growth and no measured latency penalty, making signature-based validation feasible in the near term.
  • Hybrid classical-plus-PQC cipher suites preserve the option of pairing legacy KEMs with PQC signatures, or vice versa, without collapsing performance, easing the transition before PQC-only clients are universal.
  • Operational mitigations—rate limiting, client puzzles, application-layer fragmentation, and strict cipher-suite binding—become necessary for safe deployment of the larger-signature schemes.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A testable extension beyond the paper is to repeat the benchmarks over a real wide-area network; with network round-trip time in the tens of milliseconds, the sub-10-millisecond cryptographic differences would shrink relative to transmission, which would likely widen the usability gap between MLKEM/Falcon and HQC/SPHINCS+ rather than close it.
  • The single-host, loopback testbed likely understates the cost of large signatures on shared infrastructure; under multi-tenant CPU contention, the server-CPU dominance of SPHINCS+ and HQC could translate into packet loss or timeouts, making the preference for lattice schemes even stronger in production.
  • Energy and edge-device implications follow implicitly: because SPHINCS+ inflates both transfer size and CPU, resolvers with tight power budgets would face disproportionate costs, so protocol-level fragmentation and caching optimizations deserve priority in standardization alongside algorithm choice.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper presents PQC-DNS, a benchmarking framework and experimental study of post-quantum cryptography applied to DNSSEC, DNS-over-TLS (DoT), and DNS-over-HTTPS (DoH). The authors integrate Open Quantum Safe (OQS) libraries, oqsprovider, and a forked BIND9 (OQS-BIND) into a containerized local testbed, then measure latency, bandwidth, CPU, and memory for legacy-only, PQC-only, and hybrid configurations across NIST security levels 1, 3, and 5. The central claim is that lattice-based primitives such as MLKEM and Falcon provide practical latency and resource profiles, while hash-based and code-based schemes such as SPHINCS+ and HQC impose substantially larger bandwidth and processing overhead, especially under concurrency. The paper also provides a security threat taxonomy for PQC-enabled DNS and discusses deployment, sustainability, and standardization barriers.

Significance. If the measurements are interpreted within their stated environment, the paper is a useful system-level comparison: it is, to my knowledge, one of the few studies that benchmarks DNSSEC, DoT, and DoH together under PQC configurations, and it makes a concrete artifact available on GitHub. The bandwidth results, which follow from fixed key and signature sizes, are qualitatively robust and consistently show SPHINCS+ and HQC consuming several times the bandwidth of legacy and lattice-based combinations across all tables. The multi-threaded CPU findings also provide a plausible scalability picture. The main value is therefore as an empirical reference for operators considering PQC migration, provided the latency claims are properly scoped to the local, loopback testbed. The paper is honest about this limitation in Section 5, but the abstract and Section 4.3 currently overstate the strength of the latency evidence.

major comments (3)
  1. [§4.1, Tables 3-8, abstract] The latency half of the central claim is not supported by the presented measurements. The benchmark uses a local OQS-BIND resolver hosting the test domain, with queries issued over loopback; no root, TLD, or authoritative traversal occurs and no WAN RTT is included. The reported 9-20 ms values therefore include dig process startup and WSL2/Docker overhead, not end-to-end DNS resolution. The paper itself concedes in Section 5 that results are hardware-dependent and may not generalize to wide-area deployments. With a realistic WAN RTT of 20-100 ms, the 9.1 ms versus 16.4 ms gap in Table 3 becomes a small fraction of user-perceived latency. Please either add an explicit WAN-RTT sensitivity analysis, or restrict the abstract and Section 4.3 claims to CPU-bound processing and batch throughput rather than single-query 'practical latency' in real deployments.
  2. [§4.2, Algorithm 1; Tables 3-15] No statistical characterization is reported for any metric. All tables give point estimates without standard deviations, confidence intervals, or the number of repeated sessions used to compute averages. The text highlights sub-millisecond differences such as 9.10 versus 9.17 ms in Table 3 and 8.87 versus 8.84 ms in Table 4, but without variance or trial counts these differences are not statistically distinguishable. Please report dispersion measures and repetition counts for each configuration, or explicitly mark small differences as not significant. This is load-bearing because the claim that MLKEM/Falcon 'match or outperform' legacy combinations rests on such differences.
  3. [§4.3, Tables 12-15] The scalability narrative is internally inconsistent with the data. The text preceding Table 12 states that latency remains unaffected as bandwidth scales, but Table 12 shows roughly 110 ms for 100 concurrent queries versus about 9 ms for single-query tests, Table 14 shows about 1,000 ms for 1,000 queries, and Table 15 shows about 11,000 ms for 10,000 queries. This is approximately linear degradation, not unaffected latency. The paragraph must be rewritten to describe the observed near-linear scaling, and the labels '1000 concurrent queries' and '10000 concurrent queries' should be clarified: the text describes sessions of 100 workers sending one query each, so the relationship between sessions, workers, and total query count needs to be stated precisely.
minor comments (6)
  1. [§4.3, paragraph before Table 3] The phrase 'DNSSEC-enabled configurations ans security levels' contains a typo; it should read 'and security levels'.
  2. [§4.3, paragraph before Table 12] 'Meanwile' should be 'Meanwhile'.
  3. [Tables 9-11] Algorithm naming is inconsistent: Table 9 uses 'falconpadded512' and 'sphincssha2128fsimple', while Tables 10 and 11 use 'falcon512' and 'sphincssha2128f'. Please clarify whether these are intentionally different variants and use consistent names throughout.
  4. [§4.3, table formatting] The text states that the lowest numerical values in each subcategory are bolded, but the rendered tables do not show bolding. Please ensure the final PDF preserves the formatting or remove the claim.
  5. [ACM Reference Format] The reference format line lists the date as 2018; this should be updated to the actual submission year.
  6. [§4.2, CPU normalization] The normalization of /usr/bin/time 'Percent of CPU this job got' by 16 vCPUs is not standard and may obscure differences for single-threaded dig processes. Please document the raw values or justify the normalization with respect to how the tool reports CPU percentage.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the formal equations are descriptive definitions and the central claims rest on measured benchmark tables, not on fitted inputs or self-referential derivations.

full rationale

The paper's formal apparatus (Eqs. 1-4) is a set of notational definitions and additive decompositions of measured components (latency, bandwidth, CPU, memory); none of these equations presupposes the experimental outcome or is fitted to it. The central claim that MLKEM and Falcon offer practical latency and resource profiles while SPHINCS+ increases message sizes and processing overhead is supported directly by the empirical measurements in Tables 3-15, which are measured values rather than consequences of the equations. There is one self-citation ([4], Aydeger/Zeydan on quantum-resilient transition) in the introduction, but it supports only the background statement that Shor's algorithm threatens classical cryptography and does not carry the benchmark conclusions. The paper explicitly disclaims generality in Section 5 ('results are inherently hardware-dependent and may not generalize'), which mitigates rather than conceals the main external-validity risk; that limitation is about generalizability, not circularity. No load-bearing step reduces to its own input by construction, so no circularity is present.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No fitted parameters and no invented entities are present. The analysis is an empirical benchmark; the only assumptions are standard security-model axioms, a notational additive performance model, and reliance on the correctness of the OQS-BIND integration.

assumptions (3)
  • domain assumption PQC KEMs are IND-CCA2 secure and PQC signatures are EUF-CMA secure against quantum adversaries.
    Section 3.2, Security Model, assumes these properties for the threat analysis, citing [8] and [41]. This is a standard cryptographic modeling assumption.
  • domain assumption DNS resolution time decomposes additively into a TLS handshake phase and a recursive query phase, with optional DNSSEC validation time added linearly.
    Section 3.3, Equations 3 and 4, define T_Phase1 and T_Phase2 as sums. This ignores pipelining, caching, retransmissions, and parallel validation, but is used only as a notational model, not for prediction.
  • domain assumption The OQS-BIND fork correctly integrates liboqs and oqsprovider into BIND 9.19.17 so that measured handshake and validation times reflect the selected PQC primitives.
    Section 4.1 relies on this integration. Bugs or misconfiguration in the fork would invalidate the benchmark, and the paper does not provide independent verification of the integration.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Quantum-Resistant Domain Name System: A Comprehensive System-Level Study." pith.science (2026). https://pith.science/paper/H7OZCP5L

@misc{pith2026250619943,
  author       = {Pith},
  title        = {Pith review of: Quantum-Resistant Domain Name System: A Comprehensive System-Level Study},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/H7OZCP5L}},
  note         = {Machine review of arXiv:2506.19943}
}
read the original abstract

The Domain Name System (DNS) plays a foundational role in Internet infrastructure, yet its core protocols remain vulnerable to compromise by quantum adversaries. As cryptographically relevant quantum computers become a realistic threat, ensuring DNS confidentiality, authenticity, and integrity in the post-quantum era is imperative. In this paper, we present a comprehensive system-level study of post-quantum DNS security across three widely deployed mechanisms: DNSSEC, DNS-over-TLS (DoT), and DNS-over-HTTPS (DoH). We propose Post-Quantum Cryptographic (PQC)-DNS, a unified framework for benchmarking DNS security under legacy, post-quantum, and hybrid cryptographic configurations. Our implementation leverages the Open Quantum Safe (OQS) libraries and integrates lattice- and hash-based primitives into BIND9 and TLS 1.3 stacks. We formalize performance and threat models and analyze the impact of post-quantum key encapsulation and digital signatures on end-to-end DNS resolution. Experimental results on a containerized testbed reveal that lattice-based primitives such as Module-Lattice-Based Key-Encapsulation Mechanism (MLKEM) and Falcon offer practical latency and resource profiles, while hash-based schemes like SPHINCS+ significantly increase message sizes and processing overhead. We also examine security implications including downgrade risks, fragmentation vulnerabilities, and susceptibility to denial-of-service amplification. Our findings inform practical guidance for deploying quantum-resilient DNS and contribute to the broader effort of securing core Internet protocols for the post-quantum future.

Figures

Figures reproduced from arXiv: 2506.19943 by the authors.

Figure 1
Figure 1. Layered Architecture of Secure DNS 3.1 DNS Infrastructure [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Layered Protocol Sequence for PQC-DNS with DNSSEC Option [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Experimental setup used in our evaluations. [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Process Steps of Benchmarking • Latency (𝑇latency): This value is calculated based on the time (in milliseconds) it takes between the first packet for a DNS request from the client to the last packet received for that request. This metric measures the responsiveness of…
Figure 5
Figure 5. Figure 5: DoT Latency (left) and Bandwidth(right) comparison chart by Security Level 1, 3, and 5 [PITH_FULL_IMAGE:figures/full_fig_p017_5.png]
Figure 6
Figure 6. Figure 6: Multi-thread (100 Concurrent Queries) DoT Latency (left) and Bandwidth (right) comparison chart - Security Level 1 [PITH_FULL_IMAGE:figures/full_fig_p024_6.png]
Figure 7
Figure 7. Figure 7: Multi-thread (1000 Concurrent Queries) DoT Latency (left) and Bandwidth (right) comparison chart - Security Level 1 [PITH_FULL_IMAGE:figures/full_fig_p025_7.png]
Figure 8
Figure 8. Figure 8: Multi-thread (10000 Concurrent Queries) DoT Latency (left) and Bandwidth (right) comparison chart - Security Level 1 [PITH_FULL_IMAGE:figures/full_fig_p025_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

43 extracted references · 39 canonical work pages

  1. [1]

    Abirami and R

    S. Abirami and R. Naresh. 2024. DNS Enhancement with DNSSEC and DoT for Enhanced Online Security. In 2024 2nd International Conference on Networking and Communications (ICNWC) . 1–11. https://doi.org/10.1109/ICNWC60771.2024.10537516

    arXiv 2024

  2. [2]

    Basharat Ali and Guihai Chen. [n. d.]. Titan-Doh: Trust-Integrated Threat Adaptive Network for Post-Quantum Secure Dns Over Https. A vailable at SSRN 5230452 ([n. d.])

    work page

  3. [3]

    Rob Austein, Roy Arends, Matt Larson, Dan Massey, and Scott Rose. 2005. DNS Security Introduction and Requirements. RFC 4033. https: //tools.ietf.org/html/rfc4033

    work page 2005

  4. [4]

    Abdullah Aydeger, Engin Zeydan, Awaneesh Kumar Yadav, Kasun T Hemachandra, and Madhusanka Liyanage. 2024. Towards a quantum-resilient future: Strategies for transitioning to post-quantum cryptography. In 2024 15th International Conference on Network of the Future (NoF) . IEEE, 195–203

    work page 2024

  5. [5]

    GJ Beernink. 2022. Taking the quantum leap: Preparing dnssec for post quantum cryptography . Master’s thesis. University of Twente

    work page 2022

  6. [6]

    Jessica Bozhko, Yacoub Hanna, Ricardo Harrilal-Parchment, Samet Tonyali, and Kemal Akkaya. 2023. Performance evaluation of quantum-resistant TLS for consumer IoT devices. In 2023 IEEE 20th Consumer Communications & Networking Conference (CCNC) . IEEE, 230–235

    work page 2023

  7. [7]

    Lily Chen, Stephen Jordan, Yi-Kai Liu, Dustin Moody, and Rene Peralta. 2016. Report on Post-Quantum Cryptography . Technical Report NISTIR 8105. NIST. https://doi.org/10.6028/NIST.IR.8105

    doi:10.6028/nist.ir.8105 2016

  8. [8]

    Céline Chevalier, Ehsan Ebrahimi, and Quoc-Huy Vu. 2022. On security notions for encryption in a quantum world. In International Conference on Cryptology in India. Springer, 592–613

    work page 2022

Show all 43 references
  1. [9]

    Cloudflare. 2022. Post-Quantum DNS and TLS. https://blog.cloudflare.com/post-quantum-for-dns/

    2022

  2. [10]

    Viktor Dukhovni and Peter Schwabe. 2023. Don’t Reuse That Nonce: Failures in Randomness for Post-Quantum Signatures. IACR Transactions on Cryptographic Hardware and Embedded Systems (TCHES) 2023, 1 (2023), 1–24. https://doi.org/10.46586/tches.v2023.i1.1-24

    2023 doi

  3. [11]

    Christopher Goertzen and Douglas Stebila. 2022. ARRF: Application-layer Request-based Resource Fragmentation for Post-Quantum DNSSEC. In Proceedings of the 17th International Conference on A vailability, Reliability and Security (ARES) . https://doi.org/10.1145/3538969.3544435

    2022

  4. [12]

    Jason Goertzen. 2023. OQS-BIND: PQC-enabled Bind9 using Open Quantum Safe’s oqs-provider. https://github.com/Martyrshot/OQS-bind

    2023

  5. [13]

    Jason Goertzen and Douglas Stebila. 2023. Post-quantum signatures in DNSSEC via request-based fragmentation. In International Conference on Post-Quantum Cryptography. Springer, 535–564

    2023

  6. [14]

    DNSOP Working Group. 2023. Post-Quantum DNSSEC Considerations. Internet Draft, IETF. https://datatracker.ietf.org/doc/draft-dnsop-pqdnssig/

    2023

  7. [15]

    Jakob Hochstätter, Thomas Unterluggauer, and Peter Schwabe. 2023. Leaky Kyber: Practical Side-Channel Attacks on Masked Kyber. In Proceedings of the 32nd USENIX Security Symposium . USENIX Association. https://www.usenix.org/conference/usenixsecurity23/presentation/hochstatter

    2023

  8. [16]

    Paul Hoffman and Patrick McManus. 2018. DNS Queries over HTTPS (DoH). RFC 8484. https://tools.ietf.org/html/rfc8484

    2018

  9. [17]

    Zi Hu, Liang Zhu, John Heidemann, Allison Mankin, Duane Wessels, and Paul Hoffman. 2016. Specification for DNS over Transport Layer Security (TLS). RFC 7858. https://tools.ietf.org/html/rfc7858

    2016

  10. [18]

    Adam Ali.Zare Hudaib and Esra’a Ali Zare Hudaib. 2014. DNS Advanced Attacks and Analysis. International Journal of Computer Science and Security (IJCSS) 8, 2 (April 2014), 63–74. https://www.cscjournals.org/library/manuscriptinfo.php?mc=IJCSS-905

    2014

  11. [19]

    Andreas Hülsing, Joost Rijneveld, and Douglas Stebila. 2021. PQC in TLS: How to Make and Break It. In 30th USENIX Security Symposium . https://www.usenix.org/conference/usenixsecurity21/presentation/hulsing

    2021

  12. [20]

    Sevinj Jafarli. 2022. Providing DNS Security in Post-Quantum Era with Hash-Based Signatures . Master’s thesis. University of Twente

    2022

  13. [21]

    NLnet Labs. 2023. PQC Readiness in DNS. https://nlnetlabs.nl

    2023

  14. [22]

    Cameron McGowan, James Liu, and Sushmita Ruj. 2025. Security Considerations for Post-Quantum Signatures in DNSSEC via Request-Based Fragmentation. In Companion Proceedings of the ACM on Web Conference 2025 . 1189–1193

    2025

  15. [23]

    National Institute of Standards and Technology. 2022. Post-Quantum Cryptography Standardization. https://csrc.nist.gov/projects/post-quantum- cryptography

    2022

  16. [24]

    National Institute of Standards and Technology (NIST). 2015. SP 800-152: A Profile for U.S. Federal Cryptographic Key Management Systems . Special Publication SP 800-152. NIST Computer Security Division. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-152.pdf...

    2015

  17. [25]

    Syed W Shah Pan, Din Duc Nha Nguyen, Robin Doss, Warren Armstrong, Praveen Gauravaram, et al. 2024. Double-Signed Fragmented DNSSEC for Countering Quantum Threat. arXiv preprint arXiv:2411.07535 (2024)

    2024

  18. [26]

    PQDNS Project. 2022. Post-Quantum Secure DNS Prototype. https://pqdns.dev

    2022

  19. [27]

    Manohar Raavi, Simeon Wuthier, and Sang-Yoon Chang. 2024. Securing Post-Quantum DNSSEC Against Fragmentation Mis-Association Threat. In ICC 2024-IEEE International Conference on Communications . IEEE, 97–102

    2024

  20. [28]

    Arpit Rawat and Mayank Jhanwar. 2023. QBF: QNAME-Based Fragmentation for Post-Quantum DNSSEC. In IEEE Symposium on Security and Privacy Workshops (SPW). https://doi.org/10.1109/SPW59501.2023.00053

    2023

  21. [29]

    Arpit Rawat and Mayank Jhanwar. 2023. SL-DNSSEC: A Size-Optimized Post-Quantum Secure DNSSEC Protocol Using KEM and MAC. In 2023 ACM Asia Conference on Computer and Communications Security (AsiaCCS) . https://doi.org/10.1145/3579856.3592816

    2023

  22. [30]

    Arpit Rawat and Mayank Jhanwar. 2023. TurboDNS: Efficient Post-Quantum Secure DNSSEC over TCP. In 2023 IEEE International Conference on Distributed Computing Systems (ICDCS) . https://doi.org/10.1109/ICDCS58692.2023.00123

    2023

  23. [31]

    Aditya Singh Rawat and Mahabir Prasad Jhanwar. 2023. Post-quantum DNSSEC over UDP via QNAME-Based Fragmentation. In International Conference on Security, Privacy, and Applied Cryptography Engineering . Springer, 66–85

    2023

  24. [32]

    Aditya Singh Rawat and Mahabir Prasad Jhanwar. 2024. Post-Quantum DNSSEC with Faster TCP Fallbacks. InInternational Conference on Cryptology in India. Springer, 212–236

    2024

  25. [33]

    Aditya Singh Rawat and Mahabir Prasad Jhanwar. 2024. Quantum-safe Signatureless DNSSEC. Cryptology ePrint Archive (2024)

    2024

  26. [34]

    Caspar Schutijser, Elmer EH Lastdrager, Ralph Koning, and Cristian EW Hesselman. 2024. A testbed to evaluate quantum-safe cryptography in DNSSEC. In DNS and Internet Naming Research Directions, DINR 2024

    2024

  27. [35]

    Jayasree Sengupta, Mike Kosek, Justus Fries, Simone Ferlin-Reiter, and Vaibhav Bajpai. 2024. On Cross-Layer Interactions of QUIC, Encrypted DNS and HTTP/3: Design, Evaluation, and Dataset. IEEE Transactions on Network and Service Management 21, 3 (2024), 2992–3007. https: //do...

    2024

  28. [36]

    Haya Shulman and Michael Waidner. 2023. Post-Quantum DDoS: How Quantum-Safe Handshakes Can Be Weaponized. In Proceedings of the Network and Distributed System Security Symposium (NDSS) . https://www.ndss-symposium.org/ndss-paper/post-quantum-ddos-how-quantum- safe-handshakes-c...

    2023

  29. [37]

    Douglas Stebila, Scott Fluhrer, and Shay Gueron. 2016. Hybrid key exchange in TLS 1.3. IACR Cryptology ePrint Archive 2016 (2016), 1008. https://eprint.iacr.org/2016/1008

    2016

  30. [38]

    Douglas Stebila, Scott Fluhrer, and Martin Thomson. 2023. Hybrid Key Exchange in TLS 1.3. Internet-Draft draft-ietf-tls-hybrid-design-05, IETF. https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-05 Work in Progress

    2023

  31. [39]

    Google Security Team. 2023. Experimenting with post-quantum TLS in Chrome. https://security.googleblog.com/2023/08/experimenting-with- post-quantum-tls-in.html

    2023

  32. [40]

    Chris Wood, Martin Thomson, and Daniel Migault. 2023. Interoperability Considerations for Post-Quantum TLS. Internet-Draft draft-wood-tls-pqc- interoperability-01, IETF. https://datatracker.ietf.org/doc/html/draft-wood-tls-pqc-interoperability-01 Work in Progress

    2023

  33. [41]

    Keita Xagawa. 2024. Signatures with memory-tight security in the quantum random oracle model. In Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, 30–58

    2024

  34. [42]

    Yuan Zhang, Zi Hu, and Kevin Schomp. 2022. Evaluating SPHINCS+ for DNSSEC. In Proceedings of the NDSS Workshop on DNS Privacy

    2022

  35. [43]

    Jieyu Zheng, Haoliang Zhu, Yifan Dong, Zhenyu Song, Zhenhao Zhang, Yafang Yang, and Yunlei Zhao. 2024. Faster Post-quantum TLS 1.3 Based on ML-KEM: Implementation and Assessment. In European Symposium on Research in Computer Security . Springer, 123–143. Manuscript submitted to ACM

    2024

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.