Create CNSA 2.0 TLS Policies

[alexw91]

Problem:

s2n currently has a TLS Security Policy for "rfc9151" that follows the CNSA 1.0 TLS guidance.

There is a new draft RFC for CNSA 2.0 guidance here:
https://datatracker.ietf.org/doc/draft-becker-cnsa2-tls-profile/

Solution:

s2n-tls should create a few new Security Policies:

• CNSA_1.0: This policy should be an alias to the existing rfc9151 TLS Security policy
• CNSA: This policy should be a combination of CNSA 1.0 and 2.0 guidance, with 2.0 guidance being preferred over 1.0. This will allow clients time to migrate from 1.0 to 2.0.
• CNSA_2.0: This policy should follow the CNSA 2.0 guidance exactly

The specific naming of these policies is still to be decided. Alternatively these policies might be named cnsa-1, cnsa-2, cnsa-2-strict.

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links:
  • CNSA 1.0: https://datatracker.ietf.org/doc/html/rfc9151
  • CNSA 2.0: https://datatracker.ietf.org/doc/draft-becker-cnsa2-tls-profile/
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
  • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
  • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?

[johubertj]

The names will be the below for the security policies after discussing with the team (s2n-tls)

cnsa_1
cnsa_1_2_hybrid
cnsa_2