crypto/tls: Permit recently FIPS-approved protocols/algorithms

[reedloden]

What version of Go are you using (go version)?

$ go version
go version go1.21.0 darwin/arm64

Does this issue reproduce with the latest release?

Yes

What did you do?

When in FIPS-mode, BoringCrypto does not support recently permitted protocols/algorithms.

What did you expect to see?

Support for TLS v1.3 (permitted by NIST SP 800-52 Rev. 2), including cipher suites TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. See also GSA IT Security Procedural Guide: SSL/TLS Implementation CIO-IT Security-14-69. Note that TLS 1.3 support is required starting January 1, 2024.

Support for Ed25519 signature algorithm (permitted by FIPS 186-5).

FIPS 140-3 made some changes that permitted these new protocols/algorithms.

Note that BoringSSL fips-20220613 branch already supports TLS 1.3 and some other improvements by way of SSL_CTX_set_compliance_policy(ssl_compliance_policy_fips_202205). This helps bring BoringCrypto into alignment from the TLS perspective.

What did you see instead?

Only TLS v1.2 supported. No support for TLS v1.3.

No support for Ed25519 as a signature algorithm.

[gopherbot]

Change https://go.dev/cl/524355 mentions this issue: crypto/tls: support TLS 1.3 and Ed25519 signature algorithm in FIPS-mode

[ianlancetaylor]

CC @golang/security

[dagood]

Note that TLS 1.3 support is required starting January 1, 2024.

It sounds like this change is needed in 1.21 and 1.22 1.20 and 1.21 because those versions will both still be in support by then, is that correct?

(Edit: Whoops, off by one.)

[reedloden]

Note that TLS 1.3 support is required starting January 1, 2024.

It sounds like this change is needed in 1.20 and 1.21 because those versions will both still be in support by then, is that correct?

As I understand Go's release policy and release cadence, then yes. I had originally included multiple changes in my PR to address the recent FIPS / NIST improvements, but I re-scoped it solely to address the TLS v1.3 support to bring it inline with what BoringSSL already supports and due to the impending deadline. I'll open up additional PRs for other things, but it's possible some of those changes might need re-certification by NIST as part of the move to FIPS 140-3.

[FiloSottile]

The latest BoringCrypto validation, both according to the docs and to a CMVP search is certificate #4407. Its security policy specifies 853ca1ea1168dff08011e5d42d94609cc0ca2e27 as the version, which is fips-20210429.

The Approved Algorithms don't list Ed25519 (which I don't think would have been possible, since this is a FIPS 140-2 certificate). The security policy mentions TLS 1.2 in various places, but not TLS 1.3. ssl_compliance_policy_fips_202205 was added after fips-20210429 was tagged, too.

I'm afraid that we can't enable these algorithms with the current BoringCrypto module version.

The Modules In Process List has a BoringCrypto FIPS 140-3 validation In Review, for what I presume might be fips-20220613. In the past, we have upgraded to a new version of the module while it was In Review, but I can't make that call myself.

@agl, is it ok to switch to fips-20220613? What algorithms are allowed in its policy?

[reedloden]

@FiloSottile To be clear, this is an overarching issue covering the fact that FIPS 140-3 and other NIST standards have changed what's permitted (including Ed25519 as a new approved algorithm). Definitely understand that a validated module is required, but just wanted a tracking issue, as I didn't see anything similar. Great to see that BoringCrypto is undergoing FIPS 140-3 validation. Hopefully, that can be completed soon, and then we can way more easily update Go accordingly.

Separately, #62373 is specifically around enabling TLS 1.3 using the existing fips-20210429 certified module version. The question is whether TLS 1.3 can be used under that version (especially as the security policy doesn't mention TLS 1.2 at all), or if we need to wait for fips-20220613 (or some other BoringSSL FIPS tag).

[FiloSottile]

Discussed this offline with @agl. My understanding is that on the Go side we have three imperfect options:

1. wait for fips-20220613, then enable TLS 1.3, missing the NIST SP 800-52 Rev. 2 deadline
2. upgrade to fips-20220613 while the module is in review
3. enable TLS 1.3 with fips-20210429 under the argument that the validated KDF hasn't changed

We have precedent for upgrading to an In Review module, and most consumers I have heard from are comfortable with that, so I'm picking (2). I'll open freeze exception and backport issues next week.

[reedloden]

Appreciate you following-up on this. (2) does seem like the best of the non-great options.

Just to be clear, has it been confirmed that the fips-20220613 tag is what is under review for FIPS 140-3 and not the separate fips-20230428 branch?

[FiloSottile]

I understand that fips-20220613 will be the one we'll hopefully get a certificate for the soonest.