crypto/tls: support CNSA 2.0 profile

[cameronjwest98-ux]

CNSA 2.0, which is utilized as a standard for some government solutions, has the requirements for TLS 1.3 with the cipher suite, TLS_AES_256_GCM_SHA384
With the removal of cipher selection going from 1.2 to 1.3, this blocks many of the gov clients.
I have seen this issue brought up as early as 2018.
Is there a proposed solution or recommended work around so these requirements can be met?

Many of the previous concerns were in accordance to the FIPS requirements.

previous issue: #29349

[gabyhelp]

Related Issues

• proposal: crypto/tls: add TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 support #21633 (closed)
• crypto/tls: Permit recently FIPS-approved protocols/algorithms #62372 (closed)
• crypto/tls: TLS 1.3 unable to disable non-NIST approved ChaCha20 Cipher Suite #54072
• crypto/tls: add support for additional TLS ciphers #26652 (closed)
• crypto/tls: Available ciphers list lacks AES-256 and SHA-2 based combination #9894 (closed)
• crypto/tls: Can't create a request using just one cipher suite with TLS v1.3 #68854 (closed)
• crypto/tls: TLS 1.3 ciphers are not configurable #29349 (closed)
• dev.boringcrypto: AES_128_CBC_SHA and AES_256_CBC_SHA missing in defaultFIPSCipherSuites #36647 (closed)
• crypto/tls: TLS 1.3 only negotiates weakest possible cipher #35096 (closed)
• crypto/tls: Support CipherSuite ordering in TLS1.3 #74481 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[josephlr]

#54072 is the discussion about (maybe) allowing for more Cipher Suite configuration. However, if you need FIPS compliance, you should be using boringcrypto or some other crypto backend which is compliance focused (as has been mentioned many times in the linked issues).

[josephlr]

Oh wait I forgot about https://go.dev/doc/security/fips140

Reopening this to see if folks care about a CNSA 2.0 profile.

However, this is definitely blocked by:

• crypto/tls: implement MLKEM1024 key exchange #78543 - ML-KEM-1024

@FiloSottile do we have CNSA 2.0 plans for Go's Crypto, or is the answer still "use boringssl"? I saw that you explicitly mentioned CNSA 2.0 in #78543, so I figured I'd ask.

[cameronjwest98-ux]

However, this is definitely blocked by:

• crypto/tls: implement MLKEM1024 key exchange #78543 - ML-KEM-1024

Pardon my ignorance, are you saying that MLKEM1024 requirement of CNSA 2.0 is not met by TLS 1.3?
So even if I am able to use a proxy to block a specific cipher suite to meet my req, i will still not be compliant because of MLKEM1024?

[cpu]

Perhaps something that could be slotted into #79043

[josephlr]

However, this is definitely blocked by:

• crypto/tls: implement MLKEM1024 key exchange #78543 - ML-KEM-1024

Pardon my ignorance, are you saying that MLKEM1024 requirement of CNSA 2.0 is not met by TLS 1.3? So even if I am able to use a proxy to block a specific cipher suite to meet my req, i will still not be compliant because of MLKEM1024?

CNSA 2.0 (summary link from NSA) requires:

• Encryption: AES-256
• Hashing: SHA-384 or SHA-512
• Asymmetric Key Establishment: ML-KEM-1024
  • aka FIPS 203 category 5, CRYSTALS-Kyber Level V
• Digital Signatures: ML-DSA-87:
  • aka FIPS 204 category 5, CRYSTALS-Dilithium Level V

The only TLS 1.3 CipherSuite compatible with those requirements is TLS_AES_256_GCM_SHA384 (0x1302). But you would also need:

• A SignatureScheme for ML-DSA-87
  • This does not currently exist in TLS 1.3 as of RFC 9847
  • There is a draft IETF proposal to add it with:
    • SignatureScheme: mldsa87(0x0906)
    • AlgorithmIdentifier: id-ML-DSA-87 (2.16.840.1.101.3.4.3.19)
  • While technically still a draft, it seems fairly likely to be accepted, so it was implemented as part of crypto/x509,crypto/tls: add ML-DSA support #78888 (will be part of Go 1.27).
• A CurveID for ML-KEM-1024
  • This does not currently exist in TLS 1.3 as of RFC 9847
  • There is a draft IETF proposal to add it with:
    • NamedGroup: mlkem1024(0x0202)
  • While technically still a draft, it seems fairly likely to be accepted, so it was implemented as part of crypto/tls: implement MLKEM1024 key exchange #78543 (will be part of Go 1.27).

There's an Internet-Draft, which proposes a "CNSA Suite 2.0 Profile for TLS 1.3" that would require use of those algorithms.

IIUC the proposal here is to a have a switch (off by default) in Go's TLS library to implement such a profile.