Goal

Create the strict CNSA 2.0 TLS policy and a transitional policy from CNSA 1.0 to 2.0

Why

Define the CNSA 2.0 policy to satisfy upcoming customer use cases for ML-KEM and ML-DSA algorithms. This PR also includes an interop policy that combines CNSA 1.0 (RFC 9151) and CNSA 2.0, allowing customers to smoothly migrate from CNSA 1.0 (non-PQ) to 2.0 (PQ only).

How

1. Create the cnsa_2 policy based on the CNSA 2.0 specification. Specifically, this policy restricts the available options in TLS configurations to ensure a high security standard. The major requirements in the CNSA 2.0 Suite are as follows:

TLS Version: TLS 1.3
Cipher Suite: TLS_AES_256_GCM_SHA384
Key Exchange: ML-KEM-1024
(Certificate) Signature Scheme: ML-DSA-87

2. Add the cnsa_1_2_interop policy that combines all the supported algorithms in cnsa_2 and rfc9151. Notably, the rfc9151 policy enforces the cert key preferences, thus I added a new certificate key type for mldsa_87 gated by the ML-DSA feature flag. I also created a 'cnsa_1policy alias torfc9151` for standardization.
3. Upload the security policy snapshots and update the PQ section in the usage guide.
4. Add various test cases in s2n_pq_mlkem_policies_test.c to verify the correctness and compatibility of the cnsa_2 and cnsa_1_2_interop policies, along with small changes in existing tests to expand coverage.

Callouts

I was considering adding a check for ML-DSA support when users try to configure the cnsa_2 policy, but found out that s2n-tls could not load an ML-DSA cert if the libcrypto didn't support ML-DSA (see s2n_mldsa_test.c‎). This may serve as an alternative validation.

The current s2n FIPS rule does not consider ML-DSA (using S2N_HASH_SHAKE256_64 for hash) as FIPS-aligned. I updated the fips_hash_algs list and added ML-DSA to the test_all_fips policy.

Testing

Regarding the test certificates, I used the RFC test cert /mldsa/ML-DSA-87.crt for cnsa_2 (with the host name "LAMPS WG") and a localhost cert /permutations/ec_ecdsa_p384_sha384 for cnsa_1_2_interop.

Each policy has 5 test cases in s2n_pq_mlkem_policies_test.c. For cnsa_2, there are 2 success tests (with 1 HRR) and 3 failure tests (missing either ML-KEM-1024 or ML-DSA-87). For cnsa_1_2_interop, all 5 tests are successful with 2 non-standard policies that trigger HRR.

I also updated the pure ML-KEM interop tests in the rust bindings to use the cnsa_2 policy and verified ML-KEM-1024 and ML-DSA-87 were negotiated. TlsConfigBuilderPair loads an RSA2048 cert chain by default, which is not compatible with cnsa_2. I added an initialization method default_without_certs() as a workaround.

In s2n_security_policies_test.c, there was a check that enforces every TLS 1.3 policy to include an RSA_PSS signature algorithm. This check is only necessary when a policy supports RSA signatures in TLS 1.2 to ensure version compatibility.

Related

resolves #5152

release summary: Add the strict CNSA 2.0 TLS policy and a transitional policy from CNSA 1.0 to 2.0

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.