Better support for FIPS security policies

[lrstewart]

Problem:

s2n-tls provides very limited support for enforcing FIPS algorithm restrictions. We provide FIPS security policies, but they're manually constructed and reviewed. We also don't provide a way to make sure the policy that you choose for your FIPS endpoint is actually FIPS, beyond the policy name or documentation. This creates the potential for mistakes. The same is true for other standards, like RFC9151.

We can't take any automatic action like banning all non-FIPS algorithms when the libcrypto is in FIPS mode because customers are currently allowed to and therefore may be intentionally using non-FIPS algorithms in FIPS mode. AWSLC-FIPS is also always in FIPS mode. But if we can't automatically configure FIPS for customers, we can at least help them properly configure FIPS themselves.

Solution:

We should:

• Programmatically verify that security policies marked as FIPS actually meet the FIPS standard
• Allow applications to require that only FIPS policies be used
• Allow applications to check whether a handshake met the FIPS standard

Tasks:

• Add mechanism to enforce standards like FIPS for policies Add basic "security rules" #4298
• Check that security policies meet the expected standards 1) in unit tests 2) in s2n_init Enforce security rules on security policies #4311
• Add support for FIPS as a standard we can enforce Add FIPS security rule #4315
• Detect FIPS policies by name and automatically enforce FIPS rules
• Add mechanism to allow application to enforce standards like FIPS for configs
• Add mechanism for allow application to enforce standards like FIPS for connections

Requirements / Acceptance Criteria:

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

• RFC links: Links to relevant RFC(s)
• 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?