feat(s2n-quic): provider-crypto-fips feature flag

[toidiu]

Description of changes:

This PR exposed a new provider-fips-crypto feature flag and makes the necessary changes for s2n-quic to use FIPS-approved cryptography for encryption.

We want to support fips mode for:

• if s2n-quic-crypto fips flag is set (compile time check)
• target_os != windows (compile time check)
• negotiated cipher is not CHACHA20_POLY1305 (runtime check)

To avoid branching on the fips and windows, I throw a compiler error if the fips flag is set on windows:

#[cfg(all(feature = "fips", target_os = "windows"))]
std::compile_error!("feature `fips` is not supported on windows");

To avoid branching on the CHACHA20_POLY1305 I don't derive FipsKeys when using this cipher. This was a macro level change (key!) rather than code branching, which helps with readability imo.

Call-outs:

A lot of the changes are simply converting the encrypt function to take a &mut self, which I captured in the first commit. The interesting changes are in the second commit FipsKey.

Testing:

New CI task to test with provider-fips-crypto feature enabled

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

[WesleyRosenblum]

Why provider? This feature seems different than the others in that its not changing out an actual provider

[camshaft]

I think it would be better to "extend" the s2n provider to enable fips? Something like provider-tls-s2n-fips?

[WesleyRosenblum]

its not just TLS that changes with this flag though?

[toidiu]

We are also going to end up supporting rustls so should avoid mentioning s2n-tls.

At the moment the changes include

• indirectly passing fips to aws-lc-rs, which runs TLS in fips mode
• making the AEAD implementation fips compliant, which is used directly by QUIC for encryption (not TLS)

Therefore provider-fips-crypto seemed like a good name.

[WesleyRosenblum]

Looking at the other features in s2n-quic:

• provider-address-token-default: brings in dependencies needed for the default address token provider
• provider-tls-default: enables the default TLS provider based on platform detection
• provider-event-tracing: enabled tracing provider by default

They all have to do with an existing provider, but for fips, its not actually changing anything about any of the providers, thats why I wasn't sure provider makes sense in the name here.

[toidiu]

On a related note: running into some usage issues with provider-tls-default and fips.

I listed 2 options, neither of which seem amazing.

---

I have a slight preference for "provider" since fips affects the behavior of the tls provider. All our current features are also prefixed with "provider".

[toidiu]

Discussed offline and "provider-crypto-fips" seems like a good fit. 'fips' touches more than just tls so that doesnt feel right. We dont have a crypto provider today but its possible to image that we could have one in the future so this naming would fit with configuring cypto functionality.

Thoughts @camshaft

[toidiu]

This seems to work and allows us to keep target based dependency selection: 5baaa57

[WesleyRosenblum]

I think this probably could be removed now that the custom AES code is gone. Maybe a follow up task though, since I think there are a few places that MTU isn't needed anymore

[toidiu]

Yep, also created an issue so we don't forget: #2204

[WesleyRosenblum]

could also do something like

cfg_if::cfg_if! {
  if #[cfg(feature = "fips")] {
    key_fips!(aes128_gcm, aead::AES_128_GCM, 128 / 8, 16);
    key_fips!(aes256_gcm, aead::AES_256_GCM, 256 / 8, 16);
  } else {
    key_not_fips!(aes128_gcm, aead::AES_128_GCM, 128 / 8, 16);
    key_not_fips!(aes256_gcm, aead::AES_256_GCM, 256 / 8, 16);
  }
}
key_not_fips!(chacha20_poly1305, aead::CHACHA20_POLY1305, 256 / 8, 16);