4 ms·

So if AES were broken you'd want the TLS version bumped, some people to spend a caffeine-fueled week implementing and testing a new ciphersuite while global eco

So if AES were broken you'd want the TLS version bumped, some people to spend a caffeine-fueled week implementing and testing a new ciphersuite while global ecommerce slows to a crawl, and then OS maintainers and IT admins everywhere to get the new openssl/nss/schannel versions installed ASAP? How is that better than having pluggable ciphers? I don't really understand the combining of symmetric, asymmetric, and hash under one ciphersuite id namespace either. It's like the SSL/TLS authors had never encountered the DRY concept before. It makes adding or removing a cipher or hash into a tedious exercise, getting particular combinations into RFCs.

rdl 13y ago
If AES is broken, I'm willing to accept flag day hell, in exchange for not having 8908494 possible combinations to test and implement every time before that. It's much more likely "AES minor vulns found" happens over a period of years; the push to change algorithms happens somewhat more reasonably like most security patches. Taking a year to get rid of MD5, DES, SHA1, etc. through protocol version upgrades isn't any worse than 5-10 (and counting) we got by allowing pluggability. In the SaaS, browser, and mobile client world, upgrading software and upgrading configs aren't that different in pain, in practice.
- harshreality 13y ago
  If the implementations of hashes and various ciphers are done properly, and the combinations were truly pluggable rather than hardcoded as individual ciphersuites, you don't need to test every combination (other than for interop, to ensure that nobody else has stupid bugs due to not implementing them in a truly pluggable manner). What's the theory, that SHA3-256 that passes basic validation tests and has been audited, still won't hash certain things properly? Or that Salsa20, properly audited and validated, will work with 256 bit ecdsa but not 384 bit? Getting rid of MD5, DES, and SHA1 is easy with pluggable algorithms. Just remove those ciphersuites from the ssl implementations. The reason it's a pain in the ass to get rid of those old ciphers and hashes is not that the algorithms are pluggable, it's that nobody wants to force everyone else to upgrade (and force other ssl implementations to implement enough new ciphersuites that the old ones can be removed), right?

rdl 13y ago

If AES is broken, I'm willing to accept flag day hell, in exchange for not having 8908494 possible combinations to test and implement every time before that. It's much more likely "AES minor vulns found" happens over a period of years; the push to change algorithms happens somewhat more reasonably like most security patches. Taking a year to get rid of MD5, DES, SHA1, etc. through protocol version upgrades isn't any worse than 5-10 (and counting) we got by allowing pluggability. In the SaaS, browser, and mobile client world, upgrading software and upgrading configs aren't that different in pain, in practice.

harshreality 13y ago
If the implementations of hashes and various ciphers are done properly, and the combinations were truly pluggable rather than hardcoded as individual ciphersuites, you don't need to test every combination (other than for interop, to ensure that nobody else has stupid bugs due to not implementing them in a truly pluggable manner). What's the theory, that SHA3-256 that passes basic validation tests and has been audited, still won't hash certain things properly? Or that Salsa20, properly audited and validated, will work with 256 bit ecdsa but not 384 bit? Getting rid of MD5, DES, and SHA1 is easy with pluggable algorithms. Just remove those ciphersuites from the ssl implementations. The reason it's a pain in the ass to get rid of those old ciphers and hashes is not that the algorithms are pluggable, it's that nobody wants to force everyone else to upgrade (and force other ssl implementations to implement enough new ciphersuites that the old ones can be removed), right?