On Thu, Feb 06, 2014 at 09:57:34PM +0000, gegard4321-bugzi...@yahoo.co.uk wrote: > Regarding the other variants of AES-GCM > -TLS_RSA_WITH_AES_128_GCM_SHA256 > There are some sites support AES-GCM that use only ciphers with RSA key > exchange. I think it would be best not to support new standards that > don't provide Forward Secrecy, but on the other hand, if this cipher is > enabled then users browsing to those sites will at least have something > better than RSA with AES-CBC. If I'm correct, AES-GCM is not vulnerable to > some of the newer TLS attacks, in particular Lucky13. Even when used together > with TLS 1.2, AES-CBC is > vulnerable to Lucky13.
Lucky13 is a timing attack on MAC-then-Encrypt, which CBC uses. This attack can be fixed, but it's harder to get this right than it should be. Maybe you're refering to the BEAST attack instead of Lucky 13, which TLS 1.1 fixed and can be worked around in older versions by splitting? Anyway, I see no need for adding support for ciphers that do not support forward secrecy. > -TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > I'm > aware that a lot of sites only use 1024 bit DH, but with the patent > issues regarding ECC, there are still enough sites who don't support > ECDHE. If this cipher is enabled, users can benefit both from protection > against Lucky13 and Forward Secrecy. Also there are enough sites out > there that do have 2048 or even 4096 bit DH key exchange. Please name a few of those sites that have > 1024 DH keys. > For sites > that have both ECDHE and DHE ciphers enabled, ECDHE variants are usually > the preferred anyway and if the server has no preference, they are also > preferred by NSS. I also think that diversity should be maintained in > case a vulnerability in some standard or protocol is discovered. Just > like supporting ChaCha20_Poly1305 and AES with other modes like CCM to avoid > the same > disaster as with the BEAST attack, where AES-CBC was the only really > secure protocol, found vulnerable and then having tons of sites switch > back to the insecure RC4. Just in case ECC is being discovered > vulnerable, there should be an alternative key exchange method that does not > use EC cryptography. The only widely used are RSA and DHE, and DHE > supports Forward Secrecy and is the better alternative IMO. Some of the curves using by ECDHE might have some problems which is why people are working on getting alternatives like curve25519 standardized. But DHE is so slow that people want to avoid it, and there are both clients and servers have problems with sizes of 2048 or more which really is what you want. But I can understand that some people might prefer DHE instead of ECDHE. And I've actually requested that this cipher would be enabled too. > Bruce Schneier believes ECC is relatively easier to break for the NSA. > Whether or not you find his advice important, the fact is that ECC is > relatively new and there should at least be one older and proven method as > well. I understand that RSA is expected to get broken in the next 10 years and we need alternatives. ECDSA is currently the only other standardised method for using in TLS that we should consider using as far as I know. I would also like to point out that EC isn't exactly new, it's just seeing more wide deployment now. So I'm actually concerned that in the long run all of RSA, DHE and ECC will be broken and that we don't really have alternatives. But we have to go with what we currently know. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
