Transport Layer Security Working Group G. Wang, Ed. Internet-Draft Huawei Int. Pte Ltd Intended status: Standards Track 2 November 2026 Expires: 6 May 2027 Recommendations for Post-Quantum Signature Algorithms in TLS 1.3 draft-wang-tls-pq-sig-recommend-00 Abstract With over 30 distinct post-quantum and hybrid/composite signature algorithm parameters proposed or registered for TLS 1.3 [RFC9847] [IANA-TLS] [I-D.ietf-tls-composite-mldsa], implementations face increasing complexity and deployment overhead. This document provides curated guidance to recommend a manageable subset of post- quantum signature schemes for standard TLS 1.3 deployments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Wang Expires 6 May 2027 [Page 1] Internet-Draft PQ Signature Recommendations for TLS November 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. The Post-Quantum Signature Landscape . . . . . . . . . . . . 3 4. Algorithm Recommendations and Engineering Logic . . . . . . . 4 4.1. The Performance Matrix . . . . . . . . . . . . . . . . . 4 4.2. Profile A: General-Purpose Handshake Authentication . . . 5 4.3. Profile B: Long-Term Certificate Authority Trust Anchors . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The rapid advancement of quantum computing structures introduces severe systemic risks to prevailing public-key infrastructures (PKIs) globally. Traditional cryptographic primitives—primarily those reliant on integer factorization, finite field discrete logarithms, or elliptic curve discrete logarithms—are inherently vulnerable to polynomial-time quantum cryptanalysis via Shor's algorithm. To preemptively mitigate these threats, the cryptographic community has initiated a wholesale transition toward post-quantum (PQ) cryptography and hybrid post-quantum/traditional (PQ/T) architectures across core transport layer validation frameworks. Within the context of Transport Layer Security (TLS) version 1.3 [RFC8446] [RFC9846], this migration has triggered a massive expansion of the signature scheme namespace. Various working groups within the Internet Engineering Task Force (IETF) and the broader cryptographic ecosystem have introduced an extensive library of algorithm specifications. Specifically, 16 distinct composite ML-DSA combinations [I-D.ietf-tls-composite-mldsa] have been proposed to use in TLS 1.3, alongside 3 standalone pure ML-DSA parameter sets [I-D.ietf-tls-mldsa] [IANA-TLS] and 12 stateless hash-based SLH-DSA parameter variations [I-D.reddy-tls-slhdsa] [IANA-TLS]. When aggregated across the Internet Assigned Numbers Authority (IANA) registries [IANA-TLS], over 30 separate post-quantum and hybrid signature schemes are now available for session negotiation and certificate chain path building. While this wide array of parameters offers flexible trade-offs between performance, signature boundaries, and mathematical hardness assumptions, it simultaneously introduces a critical challenge: implementation complexity. Requiring TLS engines to store, process, and negotiate an unmanaged number of code points invariably leads to Wang Expires 6 May 2027 [Page 2] Internet-Draft PQ Signature Recommendations for TLS November 2026 increased software attack surfaces, potential interoperability friction, and inefficient ClientHello negotiations. Furthermore, the inclusion of heavy signature options can induce network-level penalties, such as packet fragmentation and increased time-to-last- byte metrics across volatile or lossy connection channels. To prevent systemic fragmentation of the TLS ecosystem, this document provides structured deployment profiles that identify a curated, highly interoperable subset of post-quantum signature schemes. By delineating clear boundaries between general-purpose handshake authentication and long-term certificate authority trust anchors, these recommendations enable protocol implementers to align with strict regulatory frameworks while keeping operational execution costs manageable. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. The Post-Quantum Signature Landscape The post-quantum signature options currently specified for use within TLS 1.3 [RFC8446] originate from two fundamentally distinct mathematical families standardized by NIST: module-lattice-based cryptography and stateless hash-based cryptography. Each family presents varying engineering trade-offs regarding computational execution times, public key boundaries, and signature verification payloads. Understanding these characteristics is essential for analyzing how different algorithms affect standard TLS handshakes and packet processing pipelines. The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) [FIPS204] represents the primary general-purpose public-key signature framework for post-quantum migration. Derived from the Crystals- Dilithium primitive, ML-DSA is specified across three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87, mapped respectively to the TLS SignatureScheme namespace as mldsa44, mldsa65, and mldsa87 [I-D.ietf-tls-mldsa]. ML-DSA achieves a highly optimized balance between public key generation, signing speed, and verification efficiency. Its signature sizes range from roughly 2,420 bytes to 4,595 bytes. While significantly larger than traditional elliptic curve or RSA signatures, these sizes generally fit within standard TCP initial window limits without triggering extensive packet fragmentation. Wang Expires 6 May 2027 [Page 3] Internet-Draft PQ Signature Recommendations for TLS November 2026 Conversely, the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) [FIPS205], derived from SPHINCS+, relies on the conservative security assumptions of symmetric hash functions (such as SHA-256 or SHAKE256). SLH-DSA introduces zero new structural mathematical hardness assumptions beyond the collision resistance of its underlying hash primitives. This property makes it exceptionally resilient against prospective lattice cryptanalysis breakthroughs. However, this robust security comes with heavy performance trade- offs. Across its 12 registered variations [I-D.reddy-tls-slhdsa], the "small" (S) variants minimize payload size at the cost of slower signing speeds, yet still produce signatures ranging from 7,856 bytes to nearly 30 kilobytes. The "fast" (F) variants accelerate signature production but increase verification overhead and result in much larger transmission payloads. This substantial size boundary introduces a persistent risk of network-level disruptions, such as middlebox drops caused by fragmented UDP packets in DTLS environments. To bridge the operational gap during this multi-decade migration, Composite ML-DSA signature schemes [I-D.ietf-tls-composite-mldsa] have been introduced as a transitional framework for Post-Quantum/ Traditional (PQ/T) hybrids. A composite scheme packages both a post- quantum algorithm (such as ML-DSA) and a classical primitive (such as ECDSA, Ed25519, or RSA) into a single cryptographic element. Protocol logic treats this combination as a single opaque identifier, executing both signing and verification routines sequentially. Authentication succeeds if and only if both component signatures are verified as structurally valid. This architecture provides robust defense-in-depth, protecting session security even in the event of an unforeseen structural break in early post-quantum lattice primitives or their initial software implementations. 4. Algorithm Recommendations and Engineering Logic Selecting post-quantum signature schemes for TLS 1.3 requires navigating a multi-dimensional engineering trade-off matrix consisting of payload size, processing latency, and security longevity. Ecosystem fragmentation can be avoided by dividing recommendations into distinct deployment profiles based on operational roles. The following is a preliminary recommendation. 4.1. The Performance Matrix To establish baseline engineering logic, the structural metrics of the candidate algorithms are compared below. Byte overhead figures represent the combined total of the public key and the signature payload, which directly impacts the TLS handshake packet footprint. Wang Expires 6 May 2027 [Page 4] Internet-Draft PQ Signature Recommendations for TLS November 2026 +==============================+=========+=======+============+============+ |Signature Scheme Identifier | Public |Signing|Verification|Primary | | | Key & |Latency| Latency |Mathematical| | |Signature| | |Assumption | | | (Bytes) | | | | +==============================+=========+=======+============+============+ |mldsa65 | 5,251 | Low | Very Low |Module | | | | | |Learning | | | | | |With Errors | | | | | |(M-LWE) | +------------------------------+---------+-------+------------+------------+ |mldsa65_ecdsa_secp256r1_sha512| 5,379 | Low- | Low |Dual: M-LWE | | | | Medium| |and Elliptic| | | | | |Curve ECDSA | +------------------------------+---------+-------+------------+------------+ |slhdsa_shake_128s | 7,888 | High | Low-Medium |Symmetric | | | | | |Hash | | | | | |Function | | | | | |Strength | +------------------------------+---------+-------+------------+------------+ |slhdsa_shake_192s | 16,272 | High | Medium |Symmetric | | | | | |Hash | | | | | |Function | | | | | |Strength | +------------------------------+---------+-------+------------+------------+ Table 1: Post-Quantum Signature Scheme Resource Metrics 4.2. Profile A: General-Purpose Handshake Authentication For standard ephemeral TLS handshakes where minimal time-to-last-byte (TTLB) and low CPU utilization are critical constraints, mldsa65 is RECOMMENDED as the default pure post-quantum baseline scheme. As demonstrated in Table 1, the ~5.2 KB overhead of mldsa65 allows the handshake transmission to comfortably fit within standard TCP Initial Congestion Window limits (typically 10 packets or ~14.6 KB) without triggering multi-round-trip IP fragmentation anomalies. For deployments governed by transitional regulatory mandates or requiring cryptographic risk mitigation against prospective lattice flaws, the composite signature scheme mldsa65_ecdsa_secp256r1_sha512 is RECOMMENDED. The incremental transmission cost of adding the classical ECDSA layer is negligible (+128 bytes), while the processing overhead remains well within the operational tolerances of modern hardware accelerators. Wang Expires 6 May 2027 [Page 5] Internet-Draft PQ Signature Recommendations for TLS November 2026 4.3. Profile B: Long-Term Certificate Authority Trust Anchors The engineering logic shifts significantly when evaluating root and intermediate Certificate Authority (CA) trust anchors. Because trust anchors and intermediate certificates are infrequently updated and are often cached by relying parties, signature verification reliability and long-term security safety take precedence over signature size limits. For these scenarios, SLH-DSA variants—specifically slhdsa_shake_128s—are RECOMMENDED for signing long-lived intermediate and root structures. By trading away signing performance, the small ("s") variants limit the byte boundary inflation to under 8 KB, ensuring compatibility with standard X.509 certificate path parsers. Leveraging the conservative symmetric assumptions of SHAKE256 ensures that the root anchor framework remains secure against algorithmic breakthroughs targeting lattice geometry, providing a secure foundation throughout the post-quantum migration era. 5. Acknowledgments To be added later. 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . [RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025, . Wang Expires 6 May 2027 [Page 6] Internet-Draft PQ Signature Recommendations for TLS November 2026 [FIPS204] National Institute of Standards and Technology, "FIPS 204: Module-Lattice-Based Digital Signature Standard", Federal Information Processing Standards Publication , August 2024, . [FIPS205] National Institute of Standards and Technology, "FIPS 205: Stateless Hash-Based Digital Signature Standard", Federal Information Processing Standards Publication , August 2024, . [I-D.ietf-tls-composite-mldsa] Reddy.K, T., Hollebeek, T., Gray, J., Fluhrer, S., and D. Van Geest, "Use of Composite ML-DSA in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-composite-mldsa- 00, 23 October 2026, . [I-D.ietf-tls-mldsa] Hollebeek, T., Schmieg, S., and B. Westerbaan, "Use of ML- DSA in TLS 1.3", Work in Progress, Internet-Draft, draft- ietf-tls-mldsa-06, 11 September 2026, . [I-D.reddy-tls-slhdsa] Reddy.K, T., Hollebeek, T., Gray, J., and S. Fluhrer, "Use of SLH-DSA in TLS 1.3", Work in Progress, Internet-Draft, draft-reddy-tls-slhdsa-02, 17 November 2025, . [IANA-TLS] "Transport Layer Security (TLS) Parameters", the Internet Assigned Numbers Authority (IANA) , . 7. Informative References [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, June 2025, . Author's Address Wang Expires 6 May 2027 [Page 7] Internet-Draft PQ Signature Recommendations for TLS November 2026 Guilin Wang (editor) Huawei Int. Pte Ltd 9 North Buona Vista Drive, #13-01 The Metropolis Tower 1 SINGAPORE 138588 Singapore Email: wang.guilin@huawei.com Wang Expires 6 May 2027 [Page 8]