crypto/tls: boringcrypto restricts RSA key sizes to 2048 and 3072

[riraccuia]

Is there a reason why the IsBoringCertificate() check would not allow RSA key sizes > 3072 ?

Specifically, I am trying to establish a TLS connection to a corporate server that has an intermediate CA whose key size is 4096 and it throws:
tls handshake failed: x509: certificate specifies an incompatible key usage

Seems like this was recently discussed in golang-nuts ( https://groups.google.com/g/golang-nuts/c/DbzPtRDtVgQ ) but i found no open issue here.

@FiloSottile

[FiloSottile]

@agl, it looks like there's a good argument for NIST having clarified they'll take 4096. Should we allow it?

[kumpfdp]

This would be great to be included. Today, we're having to manually apply a patch to that line of code.

[agl]

Having looked into this, it doesn't appear that allowing other modulus sizes is strictly compliant with the current validation. However, future validations can be updated to take advantage of the increased flexibility now allowed by the IG. We expect to do this, but have no timelines to announce and do not currently have a revalidation in progress.

[sfc-gh-dwu]

It's 2021 now, any update on when we can get 4096bit validated?

[evanye]

It's 2022 now. Any update on when we can get 4096 bits validated?

[agl]

It's 2022 now. Any update on when we can get 4096 bits validated?

It's been nearly a year since we did a new validation that includes RSA 4096. I'm afraid NIST can take as long as they take—we've no ability to speed up their processing.

[cipherboy]

Per closed duplicate #53755:

Per Hashicorp's recent discussions with Leidos around a Letter of Attestation for Vault based on BoringCrypto's 3678 certificate, larger key sizes are allowed. In particular, this limitation shouldn't be necessary as, per our lab contact (and with permission to quote in the interest of getting this change upstreamed):

P. said:

FIPS 140-2 IG A.14 allows for one to use RSA key sizes >= 2048 bits, so long as the ones that are testable have been tested. At the time of the BoringCrypto certification, only up to 3072 was testable, so IG A.14 would allow you to use anything above that as well.

Since the relevant BC certificate has both 2048 and 3072 tested, we sould simplify the check to >= 2048.

Let me know if this is agreeable and I can open a PR.

(TL;DR: Leidos confirmed any key size >= 2048 is safe to allow under FIPS 140-2 IG A.14, and the existing cert without 4096-bit tested is sufficient for 4096-bit keys, as 4096-bit wasn't a testing target when the existing cert was released).

[evanye]

@cipherboy that's great news! please keep us updated on which go version this can be merged into, so that we can stop using our fork of boringcrypto :)

[rolandshoemaker]

@agl as the resident FIPS person, do you have an opinion on this?

[irbekrm]

Awesome to hear that we might be able to use 4096 bit RSA keys!
Would be great to know when/if the TLS check in boring Go is going to updated- we also would like to use 4096 bit keys and now that we know it might be compliant, we have to decide between forking 'boring' Go to apply a patch or waiting for an update to the TLS check 😅

[danisevas]

So with what @cipherboy wrote, can a fix be added to version 1.20?

[Lovesmoring]

hi, will this be added to 1.20? I see #53755 has milestone go1.20 but this one hasn't

[ianlancetaylor]

Based on the discussion on this issue, no decision has been made yet.

[cipherboy]

@agl / @ianlancetaylor / @rolandshoemaker - Feel free to drop me a mail at my work email ([email protected]) if you want me to put you in touch with Leidos and our contact there if that'll help move things along.

[jaredpar]

Reading through this issue I'm confused if the sticking point is:

1. Whether FIPS 140-2 allows for this key length
2. Or whether BoringSSL has been certified for this key length

I understand a few people have asserted that (1) is allowed and that is my understanding as well. So it would seem that it's about (2) but wanted to verify that is where the issue is sitting at.

Or possible (3) just not the right resource trade off right now 😄

[cipherboy]

@jaredpar My statement above from our lab states not only that 1 is allowed, but 2 is as well. I've offered to put the Go team in touch with this lab if they desire to validate this, but gotten no inquiries. And I've also volunteered to submit a patch fixing this issue.

I believe the issue is thus 3, resource tradeoff and are likely busy with other higher priorities (purely speculation here, but perhaps they're considering a newer BC cert that might invalidate 2 due to omission of certifying higher RSA key sizes under later FIPS 140-2 IG)...

But not working on the Go team, your guess is as good as mine.

[rsc]

Talked to @agl about this. I will send a CL for Go 1.20.

[gopherbot]

Change https://go.dev/cl/447655 mentions this issue: crypto/x509: allow BoringCrypto to use 4096-bit keys

[cipherboy]

Thank you @rsc!

[rsc]

@gopherbot please backport

[gopherbot]

Backport issue(s) opened: #56671 (for 1.18), #56672 (for 1.19).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[rsc]

Only needs Go 1.19; closed the Go 1.18 backport.

[gopherbot]

Change https://go.dev/cl/449016 mentions this issue: [release-branch.go1.19] crypto/x509: allow BoringCrypto to use 4096-bit keys

[gopherbot]

Change https://go.dev/cl/449639 mentions this issue: [dev.boringcrypto.go1.18] crypto/tls: allow BoringCrypto to use 4096-bit keys