| Internet-Draft | Use of FN-DSA in TLS 1.3 | May 2026 |
| Song & Chen | Expires 7 November 2026 | [Page] |
NIST is standardizing FN-DSA as a post-quantum NTRU-lattice-based digital signature algorithm, which is expected to be published in FIPS 206. This document specifies how FN-DSA can be negotiated for authentication in TLS 1.3 via the signature_algorithms and signature_algorithms_cert extensions.¶
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 7 November 2026.¶
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.¶
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.¶
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.¶
As defined in [RFC8446], 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 [FIPS206] as follows.¶
| 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 [I-D.turner-lamps-cms-fn-dsa], 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.¶
The following table summarizes the sizes of FN-DSA public keys and signatures for each parameter set, as defined in [FIPS206]. 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.¶
| Parameter Set | Public Key (bytes) | Signature (bytes) |
|---|---|---|
| FN-DSA-512 | 897 | 666 |
| FN-DSA-1024 | 1793 | 1280 |
For the purpose of signalling support for signatures on certificates as per Section 4.2.3 of [RFC8446], these values indicate support for signing using the given AlgorithmIdentifier shown in Table 1 as defined in [I-D.turner-lamps-fn-dsa-certificates].¶
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.¶
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 [RFC8446], 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 [BD23].¶
The security considerations of [RFC8446] and [FIPS206] apply.¶
Editor's Note: This section should be expanded with FN-DSA-specific security considerations, including: random number generation requirements (see [BD23]), floating-point arithmetic implementation concerns, and side-channel attack mitigations. Specific references to [FIPS206] should be added once it is finalized.¶
This document requests new entries to the TLS SignatureScheme registry, according to the procedures in [RFC9847].¶
| Value | Description | Reconmmended | Reference |
|---|---|---|---|
| TBD1 | fndsa512 | N | This document |
| TBD3 | fndsa1024 | N | This document |
TBD.¶