Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
crypto/tls: reject TLS 1.3 ciphers in Config.CipherSuites #29349
What version of Go are you using (
I understand the reason to make it not configurable.
But there are only two kinds of CipherSuites.
That is to say, if the server and client are both written in Go,
Besides the documentation, I think this can be reconsidered or maybe
The TLS 1.3 implementation should at least allow the developer to select cipher suites from the supported set of cipher suites and change the priority of the supported cipher suites.
Why? It is obvious that the security assessment of the ciphers defined by TLS 1.3 might change. I'm old enough to know that SHA1 was the recommended hash algorithm for quite some time. Allowing the developer to exclude an algorithm gives him a chance to react for instance to meet internal compliance requirements while the cipher suite must still be supported in general to support users with legacy software.
The capability to mask interoperability issues with another TLS implementation instantly, is another reason to provide developers with the capability to change priorities of the supported algorithms.
Configuration is necessary if the ecosystem has issues that require manual mitigation. The TLS 1.3 ecosystem thankfully doesn't yet, so until it's necessary we will not add a config option. Cipher suites happen to be something that required configuration in TLS 1.2, but by the argument that everything should be configurable in case it becomes necessary later, there are half a dozen axes in TLS 1.3 (cipher suites, groups, signature algorithms, certificate signature algorithms, PSK modes...) and we are not adding a config option for each.
Returning an error if
Yes, the usage of cryptogragraphic methods must be configurable. Beside the two reasons, change of security assessment of a cryptographic algorithm and handling of interoperability issues, I have already given, there is a third one: compliance to government or internal policies. Such a policy might forbid ChaCha20, because the algorithm is not supported by government standards. How does a developer address such a requirement?
Not everybody shares your assessment that ciphers in TLS 1.3 have no issues. Dan Bernstein and Tanja Lange regard P256 as unsafe as documented in https://safecurves.cr.yp.to/. Apparently the Go implementation shares that assessment, because it prefers X25519 over P256. Burt what about developers that want to disable P256 completely?
referenced this issue
Jan 17, 2019
Let me write at first that I'm aware that you were deeply involved in the development of TLS 1.3. I watched your presentation at the Chaos Communication Congress regarding it. I appreciate the work you put in the development in the new algorithm specifically the work on TLS 1.3.
Let me clarify the point regarding P265. In my opinion every TLS implementation should at least provide the capability to disable any cryptographic algorithm for which there are multiple alternatives available independent how they are negotiated in the protocol. So my ask is actually independent of the cipher suites.
The rationale is:
Since I'm not providing patches to do what I see as necessary, I will stop discussing the point any further. I'm convinced that you and I want the best for the Golang community while we disagree that this