Repository: go
Issue: crypto/tls: TLS 1.3 unable to disable non-NIST approved ChaCha20 Cipher Suite
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

`go version go1.18.4 linux/amd64`

### Does this issue reproduce with the latest release?

yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
golang:1.18:4 docker image

</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->

Attempted to disable the ChaCha20 TLS 1.3 suite as it is not approved by NIST yet by removing it from cipher list:

```go
package main

import (
	"crypto/tls"
	"log"
	"net/http"
)

func main() {
	server := http.Server{
		Addr: "localhost:2443",
		TLSConfig: &tls.Config{
			CipherSuites: []uint16{tls.TLS_AES_256_GCM_SHA384,tls.TLS_AES_128_GCM_SHA256},
			MinVersion:   tls.VersionTLS13,
		},
	}
	log.Fatal(server.ListenAndServeTLS("localhost.pem", "localhost-key.pem"))
}
```

I then tried to force a client to choose the ChaCha20 suite:

```
openssl s_client -connect localhost:2443 -ciphersuites TLS_CHACHA20_POLY1305_SHA256
``` 


### What did you expect to see?

To error when a client tries to force the ChaCha20 cipher suite to be used

### What did you see instead?

```
---
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
````

### Background

FIPS 140-3 seems to be approving all the components of TLS 1.3 except the ChaCha20 suite. This has ruffled many feather as this Public [Response](https://www.nist.gov/system/files/documents/2022/01/18/Veritas%20Consumer%20Labeling%20Review%20Comments.pdf) on the NIST website points out:


>Limiting the label to only NIST approved cryptography seems overly restrictive. For example,
>software may include support for TLS 1.3, which can include ChaCha20/Poly1305 and neither of
>those are NIST approved as of today.


The response doesn't point out that there is a CAVP for T[LS 1.3 Key Derivation Function](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/programmatic-transitions#:~:text=December%2031%2C%202020-,TLS%201.3%20KDF,-RFC%208446%20%2D%20Sections) so that looks like it is going to be accepted/tolerated, but there seems to be active silence regarding ChaCha20.  There is seemingly no way currently to get it approved. 

Regarding issue ##29349, it basically left off with:
> what would work here would be to open a new one about a use case (not about a specific solution) with supporting information to show what the requirements are like and how common they are

So that is what I am trying to do. NIST can very well change its mind and approve ChaCha20, but it right now there is no real indicator that they will and many indicators that TLS 1.3 will be approved in FIPS environments without it.