Thanks for the clarification. Being able to disable cipher suites in TLS <= 1.2 takes care of a lot of my concerns. It does still remain a concern for 1.3.
I still do worry about the lack of ability to disable cipher suites. Does that extend to not being able to say "I will only accept certificates signed with RSA?" Because if you are forced to allow EC certificates then there are a couple points in the past where this could have been an issue ( https://www.cvedetails.com/cve/CVE-2019-6486/ and https://www.cvedetails.com/cve/CVE-2021-3114/ ). Furthermore if we imagine a future where an issue is found with how one of the ciphersuites is implemented (say ChaCha20 is done incorrectly and we only want to allow AES-GCM) then being able to disable the known bad ciphersuite is a great band-aid.
Let's say that you are providing a Go application to a customer. The customer can configure the application with a config file that controls TLS params. If you can configure the TLS ciphersuites and an issue is found the customer turns off the ciphersuite until they can upgrade. The alternative is that you go through a chain of: vendor gets new Golang -> rebuilds application -> does in-house testing to make sure nothing else came in the new Golang that broke stuff -> customer gets new application -> customer does their own in-house testing -> finally it gets deployed. It's a way longer cycle if you rely on upstream to push changes in code.
Why do TLS issues need to get patched faster than any other security vulnerability? Or said another way, why is a slow deploy cycle ok for non-TLS vulnerabilities?
So far I haven’t heard any good reason. TLS issues are not more common than other components, at least in Go. Maybe people are just a little traumatized by how often other TLS stacks broke in the past?
We maintain two Go versions with very conservative patch releases specifically to allow quick deployment of critical and security fixes. If that still doesn’t allow for quick patching of security vulnerabilities, it sounds like a process issue (on our side or on the application side), not a reason to make TLS special.
> why is a slow deploy cycle ok for non-TLS vulnerabilities?
Okay, this is a fair point. I'd say that TLS is something where fixing it faster than the baseline is possible, if it had configurable knobs. In general we should of course strive to have fast deploy cycles for security vulnerabilities of all kinds.
I still do worry about the lack of ability to disable cipher suites. Does that extend to not being able to say "I will only accept certificates signed with RSA?" Because if you are forced to allow EC certificates then there are a couple points in the past where this could have been an issue ( https://www.cvedetails.com/cve/CVE-2019-6486/ and https://www.cvedetails.com/cve/CVE-2021-3114/ ). Furthermore if we imagine a future where an issue is found with how one of the ciphersuites is implemented (say ChaCha20 is done incorrectly and we only want to allow AES-GCM) then being able to disable the known bad ciphersuite is a great band-aid.
Let's say that you are providing a Go application to a customer. The customer can configure the application with a config file that controls TLS params. If you can configure the TLS ciphersuites and an issue is found the customer turns off the ciphersuite until they can upgrade. The alternative is that you go through a chain of: vendor gets new Golang -> rebuilds application -> does in-house testing to make sure nothing else came in the new Golang that broke stuff -> customer gets new application -> customer does their own in-house testing -> finally it gets deployed. It's a way longer cycle if you rely on upstream to push changes in code.