Recommendations for Post-Quantum Signature Algorithms in TLS 1.3

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.¶

Table of Contents

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 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.¶

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.¶

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.¶

5. Acknowledgments

To be added later.¶

Author's Address