]> China Mobile

BeiJing China chenmeiling@chinamobile.com

ZTE Corp.

song.xueyan2@zte.com.cn

Security TLS Internet-Draft Post-Quantum TLS 1.3 Composite Signature FN-DSA Compositing the post-quantum FN-DSA signature with traditional signature algorithms provides protection against potential breaks in either component. This document specifies how such a composite signature can be used for authentication in TLS 1.3. The selection of composite algorithms is intentionally chosen to strictly mirror the composite strategies for ML-DSA. This alignment provides two distinct and predictable security tiers for hybrid signatures, ensuring a consistent approach to post-quantum transition across the ecosystem.

Introduction The advent of quantum computing poses a significant threat to current cryptographic systems. During the transition to post-quantum cryptography (PQC), cautious implementers may opt to combine cryptographic algorithms such that an attacker would need to break all of them simultaneously to compromise the protected data. These mechanisms are referred to as Post-Quantum/Traditional (PQ/T) Hybrids . One practical way to implement a hybrid signature scheme is through a composite signature algorithm. In this approach, the composite signature consists of two signature components, each produced by a different signature algorithm. FN-DSA is a post-quantum signature scheme standardized by NIST. This memo specifies how a composite FN-DSA signature can be negotiated for authentication in TLS 1.3 via the "signature_algorithms" and "signature_algorithms_cert" extensions. The composite algorithms defined herein are based on the framework specified in . A key design goal of this specification is to ensure consistency across the emerging post-quantum ecosystem. To that end, the selection of algorithm pairings in this document is intentionally aligned with the choices made for ML-DSA in draft-ietf-lamps-pq-composite-sigs. This creates two clear security tiers, allowing organizations to treat FN-DSA and ML-DSA composites at the same security level as interchangeable from a policy perspective.

Conventions and Terminology 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 . "Composite FN-DSA" refers to a composite FN-DSA signature scheme as defined in . For brevity, this document uses fndsa512 and fndsa1024 in SignatureScheme names to refer to the Falcon-padded-512 and Falcon-padded-1024 variants, respectively.

Composite FN-DSA SignatureSchemes As defined in , the SignatureScheme namespace is used for the negotiation of signature schemes. This document adds new SignatureScheme values for composite FN-DSA, organized into two tiers that mirror the ML-DSA composite strategy. Composite FN-DSA is treated as an opaque signature algorithm, similar to the "PureEdDSA" algorithms in TLS 1.3 (Section 4.2.3 of ). Any hash functions used are internal to the composite algorithm itself, as specified in . When a composite FN-DSA signature scheme is used in TLS, the signing and verification operations MUST be performed on the input data as constructed by TLS (Section 4.4.3 of ). This input is then passed to the composite signature primitive, which applies its own internal domain separation. When a composite FN-DSA SignatureScheme is negotiated, the end-entity certificate presented in the TLS handshake MUST contain a public key compatible with that SignatureScheme. The schemes defined in this document MUST NOT be used in TLS 1.2 .

Signature Algorithm Restrictions The composite algorithms defined in this document are suitable for use in both the signature_algorithms and signature_algorithms_cert extensions. Consistent with TLS 1.3's requirements, all defined RSA-based composites use the RSASSA-PSS padding scheme for handshake signatures. Certificates MAY be signed with composites using RSASSA-PKCS1-v1_5, but these are not negotiated for use in the TLS CertificateVerify message.

Selection Criteria for Composite Signature Algorithms The composite signatures specified in this document are a curated set of cryptographic pairs, directly adopted from . The selection process was guided by a single, overriding principle:

• Strictly Mirroring ML-DSA Composite Strategy: The pairings for fndsa512 are identical to those for ML-DSA-44, and the pairings for fndsa1024 are identical to those for ML-DSA-87, as defined in draft-ietf-lamps-pq-composite-sigs.

This prescriptive approach ensures a consistent, two-tiered security model across the PQC signature landscape, simplifying policy development and promoting interoperability.

Mapping TLS SignatureSchemes to Composite FN-DSA The following table provides a mapping between the TLS SignatureScheme identifiers and the corresponding composite algorithm identifiers from . Mapping TLS SignatureSchemes to Composite FN-DSA Identifiers

TLS SignatureScheme	Composite FN-DSA OID Name
fndsa512_rsa2048_pss_sha256	id-fnpadded512-rsa2048-pss-sha256
fndsa512_ecdsa_p256_sha256	id-fnpadded512-ecdsa-p256-sha256
fndsa512_ed25519	id-fnpadded512-ed25519-sha512
fndsa1024_rsa3072_pss_sha512	id-fnpadded1024-rsa3072-pss-sha512
fndsa1024_ecdsa_p384_sha512	id-fnpadded1024-ecdsa-p384-sha512
fndsa1024_ecdsa_p521_sha512	id-fnpadded1024-ecdsa-p521-sha512
fndsa1024_ecdsa_brainpoolP384r1_sha512	id-fnpadded1024-ecdsa-brainpoolP384r1-sha512
fndsa1024_ed448	id-fnpadded1024-ed448-shake256

Security Considerations The security considerations discussed in apply. The primary goal is to provide hybrid security, where the composite signature remains secure as long as at least one component algorithm remains secure. Composite signature schemes do not in general preserve strong unforgeability (SUF-CMA) once the traditional component is broken. This does not impact TLS, which relies on existential unforgeability (EUF-CMA). TLS clients that support both post-quantum and traditional-only signature algorithms are vulnerable to downgrade attacks. The continuity mechanism defined in can be used to mitigate this risk.

IANA Considerations This document requests new entries to the "TLS SignatureScheme" registry, according to the procedures in . Additions to TLS SignatureScheme Registry

Value	Description	Recommended	Reference
TBD1	fndsa512_rsa2048_pss_sha256	N	This document.
TBD2	fndsa512_ecdsa_p256_sha256	Y	This document.
TBD3	fndsa512_ed25519	N	This document.
TBD4	fndsa1024_rsa3072_pss_sha512	N	This document.
TBD5	fndsa1024_ecdsa_p384_sha512	N	This document.
TBD6	fndsa1024_ecdsa_p521_sha512	N	This document.
TBD7	fndsa1024_ecdsa_brainpoolP384r1_sha512	N	This document.
TBD8	fndsa1024_ed448	N	This document.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Informative References This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. National Institute of Standards and Technology (NIST) n.d.

Acknowledgments This document also draws on draft-reddy-tls-composite-mldsa. Thanks to the authors of that document.