tls-rustls-aws-ls-sys-fips build option

[xnox]

Hi,

I see that there is tls-boring and tls-ring build flags available.

would you consider adding tls-aws-ls ? specifically to use rustls, with aws-ls-sys, with/without the fips feature flag of the latter one.

If such addition would be welcomed, let me know if you need help implementing it. The primary benefit of getting access to https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4759 CVMP cert under FIPS 140-3.

[howardjohn]

fwiw the boring crate is also has a cvmp 140-3 certification

[howardjohn]

Well actually the version currently is in the old one which is 140-2,but should be updated soon

[howardjohn]

Anyhow, from a technical standpoint it's harder to add providers than other projects since we need to do CSRs. This is the "rcgen" stuff. Might be simple but need to make sure we have a solution.

from a project standpoint I think the main thing is we want to make sure any we are are actively maintained by someone so we don't end up with a bunch of providers causing issues.

[xnox]

Basically the aws-lc is now the default rustls provider (instead of ring), and more stuff is likely standertise on it.

And the fips version of it the 2.0.0 lifecycle policy is much kinder, thus easier to deploy compliance with.

[ilrudie]

Interesting. I had not seen that rustls switched their default.

[xnox]

Interesting. I had not seen that rustls switched their default.

I think that happened in https://github.com/rustls/rustls/commit/7415b5ff3d60a988a407b4e09680a06d4c17e837

[howardjohn]

@xnox do you have a specific desire to have the AWS module or to have a FIPS validated module? Id the former, would be curious to know why

Currently the plan has been to offer boringssl as the FIPS validated module primarily, as is the same module used in Go and Envoy

[howardjohn]

If we do this one other thing I am reminded of - boringssl and aws-lc add some onerous build steps. With boring we are able to use a pre compiled build. It would be great to do this with aws as well if we adopt it.

If it's the 3rd most recommended choice I suppose build ergonomics may not be as important, though.

[xnox]

@xnox do you have a specific desire to have the AWS module or to have a FIPS validated module? Id the former, would be curious to know why

Currently the plan has been to offer boringssl as the FIPS validated module primarily, as is the same module used in Go and Envoy

My goal is to minimize number of cryptographic modules, and to ensure that FIPS/non-FIPS use as close analogous implementations as possible. For rust, today it seems that the best choice is rustls with aws-lc (in either non-fips or fips feature flags).

For go, most distributions do not use boringssl (because it allows to use many unapproved algorithms and google provides no support for such build of go and the policy is difficult to use). For go, most use OpenSSL via https://github.com/microsoft/go (or https://github.com/golang-fips/go). By most I mean: RHEL, Canonical/Ubuntu, Microsoft/Azure Linux, Chainguard Images / Wolfi OS. To achieve usable Go FIPS compliance.

Envoy in FIPS mode for now only buildable using boringssl. There is attempt to provide openssl implementation but it is of unknown production status.

Note at chainguard we do provide FIPS builds, with CVE patched dependencies of all of the above mentioned components already. But not yet ztunnel.

[xnox]

If we do this one other thing I am reminded of - boringssl and aws-lc add some onerous build steps. With boring we are able to use a pre compiled build. It would be great to do this with aws as well if we adopt it.

If it's the 3rd most recommended choice I suppose build ergonomics may not be as important, though.

I expect most distributions to provide a prebuilt aws-lc for usage in aws-lc fips crate. And the build instructions are actually fairly relaxed for asw-lc. At least they appear easier to meet than boringssl ones.

[xnox]

Some of the above points maybe very moot - in the context of ztunnel and how well coded it is. You appear to be very FIPS-friendly, intentionally picking a tiny subset of cryptography to use; and intentionally pick widely compatible, certified and popular ones.

[bleggett]

works for me as long as multiarch build support is at-least-as-robust as boring, hopefully less painful.

[howardjohn]

@xnox thanks for the additional context. Overall I think this makes sense.

Here is how I would go about it:

• Add a new config feature, opt-in, to build with aws-lc. I doubt we need to bother with a fips/non-fips flag there, under the assumption non-fips builders will be fine with ring or whatever we choose to default to.
• CI added for tests, but no OSS Istio release builds with it set (matching boring)
• We may want to do some refactoring now as we go from 2 -> 3 options but probably nothing crazy

One wrinkle around FIPS and ztunnel in general is wrt https://github.com/istio/istio/issues/52926, btw.

In terms of implementation I don't think it would be a priority from any of the current maintainers I am aware of, so if you are interested in this it would be great if you are able to contribute this directly. Happy to help with this/review the PR/etc

[xnox]

Also note https://github.com/istio/ztunnel/pull/820 which was merged

However note that rustls currently does not have a FIPS feature for the rustl-webpki depedency - see https://github.com/rustls/webpki/issues/307