Use of FN-DSA in TLS 1.3

Introduction FN-DSA (formerly known as Falcon) is a lattice-based digital signature scheme based on the Gentry-Peikert-Vaikuntanathan (GPV) hash-and-sign framework, instantiated over NTRU lattices with fast Fourier sampling techniques. The core hard problem underlying FN-DSA is the Short Integer Solution (SIS) problem over NTRU lattices. FN-DSA offers compact signatures and public keys compared to other post-quantum signature schemes. For bandwidth-constrained applications where signature size is a critical factor, FN-DSA provides a favourable alternative to ML-DSA and SLH-DSA. Editor's Note: The FN-DSA description of the whole text needs double check after FIPS206 publishment. This document specifies how FN-DSA is used for authentication in TLS 1.3, including certificate chain signatures and handshake signatures in the CertificateVerify message.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

FN-DSA Signature Scheme Values As defined in , the SignatureScheme namespace is used for the negotiation of signature scheme for authentication via the signature_algorithms and signature_algorithms_cert extensions. This document adds two new SignatureScheme values for the two FN-DSA parameter sets from as follows. SignatureSchemes for FN-DSA

SignatureScheme	FIPS 206	Certificate AlgorithmIdentifier
fndsa512(TBD1)	FN-DSA-512	id-FN-DSA-512 (2.16.840.1.101.3.4.3.TBD2)
fndsa1024(TBD3)	FN-DSA-1024	id-FN-DSA-1024 (2.16.840.1.101.3.4.3.TBD4)

Note that these are the pure (non-pre-hashed) variants of FN-DSA. Pre-hashed variants are not defined in this document. This design choice follows the convention established by IETF for other post-quantum signature algorithms in protocol bindings. As discussed in , when signature algorithms such as EdDSA, SLH-DSA, ML-DSA, and FN-DSA are used in protocol contexts where the data to be signed is typically small (such as TLS handshake transcripts or CMS signed attributes), the pre-hash mode offers no significant benefit in reducing the size of data to be signed.

Key and Signature Sizes The following table summarizes the sizes of FN-DSA public keys and signatures for each parameter set, as defined in . Two security levels of FN-DSA are recommended in this document. FN-DSA-512 is expected to offer a security level equivalent to NIST level 1. FN-DSA-1024 is expected to offer a security level equivalent to NIST level 5. Key and Signature Sizes for FN-DSA

Parameter Set	Public Key (bytes)	Signature (bytes)
FN-DSA-512	897	666
FN-DSA-1024	1793	1280

Certificate Chain For the purpose of signalling support for signatures on certificates as per Section 4.2.3 of , these values indicate support for signing using the given AlgorithmIdentifier shown in Table 1 as defined in . Implementations SHOULD validate that the public key in the end-entity certificate matches the expected size for the negotiated parameter set. A mismatch MUST be treated as a verification failure.

Handshake Signature When one of those SignatureScheme values is used in a CertificateVerify message, then the signature MUST be computed and verified as specified in Section 4.4.3 of , and the corresponding end-entity certificate MUST use the corresponding AlgorithmIdentifier from Table 1. If the signature or public key is of the wrong length, the client MUST treat this as a verification failure, and thus terminate the handshake with a decrypt_error alert. The random salt used in FN-DSA signature generation MUST be derived from a cryptographically secure random number generator. Lack of fresh random data during FN-DSA signature generation leads to a differential fault attack .

Security Considerations The security considerations of and apply. Editor's Note: This section should be expanded with FN-DSA-specific security considerations, including: random number generation requirements (see ), floating-point arithmetic implementation concerns, and side-channel attack mitigations. Specific references to should be added once it is finalized.

IANA Considerations This document requests new entries to the TLS SignatureScheme registry, according to the procedures in . TLS SignatureScheme Values for FN-DSA

Value	Description	Reconmmended	Reference
TBD1	fndsa512	N	This document
TBD3	fndsa1024	N	This document

Acknowledgements TBD.