Add new PQ TLS Policies

[alexw91]

Resolved issues:

None

Description of changes:

Creates some new PQ TLS Policies that are also FIPS compliant.

Call-outs:

RSA Key Exchange is currently FIPS compliant, but was excluded from the FIPS rules due to it being removed in upcoming 2024 FIPS standards, (further discussion here).

Rather than create the secondary S2N_FIPS_140_3_LEGACY_SUPPORT that was proposed in that previous PR, I opted to instead not add the S2N_FIPS_140_3 rule to PQ-TLS-1-2-2023-12-13.

Testing:

Unit Testing

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

[alexw91]

These RSA Key Exchange ciphers cause PQ-TLS-1-2-2023-12-13 to fail the S2N_FIPS_140_3 rule checks in s2n as they exist today, but it seems that s2n's checks might be stricter than necessary.

See this discussion about how RSA Key exchange ciphers are technically still allowed by FIPS if necessary, but no longer recommended and proposed a separate S2N_FIPS_140_3_LEGACY_SUPPORT rule.

While these guidelines do not recommend cipher suites using RSA key transport, there may be
circumstances in practice where RSA key transport is needed. For example, if an agency uses a
network appliance for regulatory or enterprise security purposes that only functions with these
cipher suites, then these cipher suites may need to be enabled.

• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf#page=60

And this NIST doc that deprecates PKCSv1.5 padding.

Effective as of the final publication of this revision of SP 800-131A, uses of PKCS 1,
version 1.5 and other RSA key-agreement or key-transport schemes that are not
compliant with SP 800-56B are deprecated.

After December 31, 2023, the use of PKCS1-v 1_5 padding scheme is disallowed.

• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf#page=21

[lrstewart]

We didn't end up including the "LEGACY_SUPPORT" version of the rule because csosto-pk was right that the FIPS docs are pretty clear that RSA kex / PKCSv1.5 is not allowed after 2023, regardless of circumstances. So I don't think the rule is stricter than necessary for RSA kex.

It's 2024 now ;)

[lrstewart]

Are there any FIPS restrictions on the pq kems, or just the classical ones?

[alexw91]

NIST published new Key Derivation standards in 2020 that allow simple concatenation of a FIPS shared secret with a non-FIPS shared secret to still be considered allowed by FIPS, which is what the draft TLS 1.3 RFC does today. So no FIPS requirements apply to the PQ KEM's, just the FIPS ECDHE curves which are already FIPS approved.

---

In addition to the currently approved techniques for the generation of the shared secret Z as
specified in SP 800-56A and SP 800-56B, this Recommendation permits the use of a “hybrid”
shared secret of the form Z′ = Z || T, a concatenation consisting of a “standard” shared secret Z that
was generated during the execution of a key-establishment scheme (as currently specified in [SP
800-56A] or [SP 800-56B]) followed by an auxiliary shared secret T that has been generated using
some other method. 

From Section 2: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf

---

3.3.  Shared secret calculation

   Here we also take a simple "concatenation approach": the two shared
   secrets are concatenated together and used as the shared secret in
   the existing TLS 1.3 key schedule.  Again, we do not add any
   additional structure (length fields) in the concatenation procedure:
   for both the traditional groups and Kyber, the shared secret output
   length is fixed for a specific elliptic curve or parameter set.

   In other words, the shared secret is calculated as

       concatenated_shared_secret = shared_secret_1 || shared_secret_2
...

   *FIPS-compliance of shared secret concatenation.* [NIST-SP-800-56C]
   or [NIST-SP-800-135] give NIST recommendations for key derivation
   methods in key exchange protocols.  Some hybrid combinations may
   combine the shared secret from a NIST-approved algorithm (e.g., ECDH
   using the nistp256/secp256r1 curve) with a shared secret from a non-
   approved algorithm (e.g., post-quantum).  [NIST-SP-800-56C] lists
   simple concatenation as an approved method for generation of a hybrid
   shared secret in which one of the constituent shared secret is from
   an approved method.

From section 3.3 of the draft Hybrid TLS 1.3 RFC: https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-09#section-3.3