4 ms·

There's no reason to be condescending to someone who has real and legitimate concerns about this decision, which was apparently taken without any discussion or

There's no reason to be condescending to someone who has real and legitimate concerns about this decision, which was apparently taken without any discussion or input from the broader security or dev community. I could be wrong, but this overall decision to take the developer out of the loop seems to be assuming that: 1) the Go developers know the current correct, precise ordering better than anyone else. I wonder if DJB or Wietse or Schneier would always agree with all of these (and future) recommendations. 2) that perfect knowledge for this version continues to be correct into the indefinite future. Next year, you might still be using Go 1.17 in production for various compatibility reasons, and a severe vuln is found in one of the cipher suites. (Let's say ChaCha20, as hard as it might be at this moment to believe that, or maybe heartbleed/crime/beast/etc never happened. Qualys SSL Labs' tests are constantly changing precisely because our knowledge about what is vulnerable changes.) But, now, it is impossible for you to fix that and take the vulnerable ciphersuite out of contention, short of forking crypto/tls.

jchw 5y ago
I’m not being condescending. Anyways, if a serious exploit is found in the TLS stack, I would expect what you would want to do is update to the inevitable security release for your current stable version of Go. They do in fact do security releases, so it shouldn’t be a huge problem. That leaves the only logical reason to need this lever as basically just one thing: you are dealing with broken software and need the cipher suite order to be suboptimal. And yes, I expect someone to need to fork the TLS stack for that, unless it’s common enough that many people would need to do that. If my TLS stack is not updating in response to new security threats, that really poses a bigger problem to me than not having the levers to try to mitigate them on my own.

jchw 5y ago

I’m not being condescending. Anyways, if a serious exploit is found in the TLS stack, I would expect what you would want to do is update to the inevitable security release for your current stable version of Go. They do in fact do security releases, so it shouldn’t be a huge problem. That leaves the only logical reason to need this lever as basically just one thing: you are dealing with broken software and need the cipher suite order to be suboptimal. And yes, I expect someone to need to fork the TLS stack for that, unless it’s common enough that many people would need to do that. If my TLS stack is not updating in response to new security threats, that really poses a bigger problem to me than not having the levers to try to mitigate them on my own.