On Wed, Feb 5, 2014 at 9:54 PM, Rasj <rasj...@gmail.com> wrote: > Where are others? For example: > TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
See https://briansmith.org/browser-ciphersuites-01.html. Also, please look at the archives of this mailing list. There have been several DOZEN of emails about the cipher suite selection on this mailing list. in particular: "This proposal does not include the new HMAC-SHA256 or HMAC-SHA384 ciphersuites that were added in TLS 1.2 since there is not a clear need for them. Given our current understanding, HMAC-SHA-1, HMAC-SHA-256, and HMAC-SHA-384 are all more-or-less equal in terms of security given how they are used in TLS. (This is HMAC-SHA, not plain SHA. Also, there is a huge difference in the ability to resist an offline attack vs. the ability to resist an online attack.) Avoiding these ciphersuites also allows us to sidestep the possibility of performance regressions from enabling TLS 1.2." > Many web-sites have only TLS_RSA_WITH_AES_256_CBC_SHA256 as kind of > strong(even without PFS) and weak RC4 and 3DES. Please provide some examples of such sites. Some of the information in my proposal is outdated. For example, it seems like we don't have constraints on handshake size, since we've discovered workarounds for those compatibility issues. So, we have more flexibility to add these cipher suites than we previously did. My main thought here is that these cipher suites aren't really increasing security, but they are decreasing performance, when they are used. We should advocate instead for cipher suites that increase security and increase performance. That means, for example, cipher suites that waste fewer bytes per record on nonces and padding. See https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 for an example of what I mean. More generally, the CBC-HMAC mode of cipher suites is outdated and should just be replaced. We have to support the older variants for backward compatibility, but I don't see much reason, right now, to add support for the new, less efficient, no-more-secure, variants. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
