>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. Yes, because CBC is vulnerable to Lucky13, using GCM will not be vulnerable, thus GCM support is important. So if some sites support GCM but not Forward Secrecy, making TLS_RSA_WITH_AES_128_GCM_SHA256 available in Firefox, they will at least be safe from Lucky13. But on the other hand I agree with you that supporting new ciphers without Forward Secrecy is undesirable.
>Please name a few of those sites that have > 1024 DH keys. I went looking for some more, but the apparently the only sites that have > 1024 DH keys are a few small sites usually concerning privacy and/or security. >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. Ah nice. I am not sure who is in charge of this decision, but I've searched for a while and found quite a few sites that support AES-GCM but not the ECDHE versions. The list includes VPN providers, a 3rd party payment provider, a 3rd party system that educational institutions use which handles student information and some more. So a lot of private and/or confidential information. I hope that this can convince the need for TLS_DHE_RSA_WITH_AES_*_GCM_SHA* https://www.ssllabs.com/ssltest/analyze.html?d=openssl.org&s=185.9.166.106 https://www.ssllabs.com/ssltest/analyze.html?d=community.openvpn.net https://www.ssllabs.com/ssltest/analyze.html?d=payment.buckaroo.nl https://www.ssllabs.com/ssltest/analyze.html?d=hartvoorinternetvrijheid.nl https://www.ssllabs.com/ssltest/analyze.html?d=system.im https://www.ssllabs.com/ssltest/analyze.html?d=ivpn.net https://www.ssllabs.com/ssltest/analyze.html?d=mullvad.net https://www.ssllabs.com/ssltest/analyze.html?d=fronter.summacollege.nl https://www.ssllabs.com/ssltest/analyze.html?d=proxy.sh https://www.ssllabs.com/ssltest/analyze.html?d=unipackworldwide.com https://www.ssllabs.com/ssltest/analyze.html?d=www.security.nl&s=213.156.0.246 https://www.ssllabs.com/ssltest/analyze.html?d=verified.de https://www.ssllabs.com/ssltest/analyze.html?d=apache-da.com https://www.ssllabs.com/ssltest/analyze.html?d=tuifly.com https://www.ssllabs.com/ssltest/analyze.html?d=techzone.ergon.ch https://www.ssllabs.com/ssltest/analyze.html?d=https-ict.nl https://www.ssllabs.com/ssltest/analyze.html?d=filezilla-project.org https://www.ssllabs.com/ssltest/analyze.html?d=socialsecurity.be https://www.ssllabs.com/ssltest/analyze.html?d=daisy.ubuntu.com&s=91.189.95.55 https://www.ssllabs.com/ssltest/analyze.html?d=www.box.com&s=74.112.185.70 >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. Hopefully alternatives will emerge in the near future. -- View this message in context: http://mozilla.6506.n7.nabble.com/Where-are-others-SHA256-cipher-suits-in-Firefox-27-tp306678p306864.html Sent from the Mozilla - Cryptography mailing list archive at Nabble.com. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
