You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 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.
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.
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.
@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 istio/istio#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
Activity
howardjohn commentedon Sep 20, 2024
fwiw the boring crate is also has a cvmp 140-3 certification
howardjohn commentedon Sep 20, 2024
Well actually the version currently is in the old one which is 140-2,but should be updated soon
howardjohn commentedon Sep 20, 2024
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 commentedon Sep 20, 2024
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 commentedon Sep 23, 2024
Interesting. I had not seen that rustls switched their default.
xnox commentedon Sep 23, 2024
I think that happened in rustls/rustls@7415b5f
howardjohn commentedon Sep 23, 2024
@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 commentedon Sep 23, 2024
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 commentedon Sep 23, 2024
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 commentedon Sep 23, 2024
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 commentedon Sep 23, 2024
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 commentedon Sep 24, 2024
works for me as long as multiarch build support is at-least-as-robust as boring, hopefully less painful.
howardjohn commentedon Sep 24, 2024
@xnox thanks for the additional context. Overall I think this makes sense.
Here is how I would go about it:
ringor whatever we choose to default to.boring)One wrinkle around FIPS and ztunnel in general is wrt istio/istio#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 commentedon Dec 24, 2024
Also note #820 which was merged
However note that rustls currently does not have a FIPS feature for the rustl-webpki depedency - see rustls/webpki#307
Add support for AWS-LC-RS TLS provider
Add support for AWS-LC-RS TLS provider
Add support for AWS-LC-RS TLS provider (#1466)