Hey,
I read #29349 and https://go.dev/blog/tls-cipher-suites carefully. It's clear that you don't want to support ordering in TLS 1.3 as all supported modes are secure enough. But what if that changes in the future?
To my understanding the AES based ciphers are preferred when HW acceleration supports that. What if a hw implementation is wrong or we just prefer Chacha20?
Overall what's the point of restricting the users' liberty here? I understand that it leaves room for misconfiguration usually to have more options, but here all current modes are secure enough according to your argument. So why would it open up possibilities for misconfig?
Thanks
Comment From: gabyhelp
Related Issues
- crypto/tls: de-prioritize AES cipher suites when lacking hardware support #41181 (closed)
- crypto/tls: TLS 1.3 only negotiates weakest possible cipher #35096 (closed)
- crypto/tls: deprecate PreferServerCipherSuites and CipherSuites ordering #45430 (closed)
- crypto/tls: TLS 1.3 unable to disable non-NIST approved ChaCha20 Cipher Suite #54072
- crypto/tls: TLS 1.3 ciphers are not configurable #29349 (closed)
Related Code Changes
Related Documentation
- Automatic cipher suite ordering in crypto/tls > FAQs
- Automatic cipher suite ordering in crypto/tls > Go’s crypto/tls and cipher suites
- Automatic cipher suite ordering in crypto/tls > Key takeaways
- Automatic cipher suite ordering in crypto/tls > A complex choice abdicated to developers
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: seankhliao
as stated before multiple times, this isn't something we will do.
Comment From: Diniboy1123
Hey,
Thanks for the quick reply. I haven't seen a statement to the arguments I stated above. I believe those are worth reconsidering. In case I missed a thread that addresses concerns related to any of my questions, feel free to link. So far I haven't seen any.