On Sun, Nov 10, 2013 at 4:39 AM, Kurt Roeckx <k...@roeckx.be> wrote: > On Sat, Nov 09, 2013 at 02:57:48PM -0800, Brian Smith wrote: >> Last week, I also learned that ENISA, a European standards group, >> recommends Camellia alongside AES as a future-proof symmetric cipher >> algorithm; see [4]. > > They recommend: > - *_AES_*_GCM_* > - *_CAMELLIA_*_GCM_* > - *_AES_*_CCM_*
Thanks. I filed bug 940119 about adding the TLS_ECDHE_*_CAMELLIA_GCM_* cipher suites. > As I already mentioned a few time, I'm still missing some of > the *_AES_*_GCM_* ciphers, specially the DHE ones. It should be easy to add TLS_DHE_*_GCM_* cipher suites to NSS. However, I am not sure it is a good idea to add TLS_DHE_*_GCM_* or TLS_RSA_*_GCM_* cipher suites to Firefox (or other browsers, for that matter). Regarding the TLS_DHE_* variants, I think that we should spend some effort on advocating support for the TLS_ECDHE variants first. In particular, you mentioned that Apache 2.2 doesn't support ECDHE. Well, I'd rather work on backporting Apache 2.4's ECDHE support to Apache 2.2 than add the TLS_[DHE_]RSA_*_GCM_* cipher suites to Firefox. Unfortunately, DHE cipher suites don't work well in current Apache 2.2 either, because of the hard-coded 1024-bit parameters. I don't think it would be reasonable to backport the better DHE support from Apache trunk to Apache 2.4 since there are compatibility issues with doing so. Also, ultimately, we'd like to use TLS_ECDHE_* cipher suites for performance reasons. Regarding the TLS_RSA_* variants, like I said before, I think we should avoid adding new cipher suites for RSA key exchange to Firefox, to encourage websites to use the ECDHE variants, which help toward minimizing the fallout of a private key compromise. I am currently expecting that the One-RTT variant of the TLS 1.3 handshake will require ECDHE support anyway. Regardless, I think we can avoid adding those things for now, and revisit this later when we see what happens with TLS 1.3 and when we see how successful (or not) our advocacy attempts are. >> I think we probably want to still disable Camellia >> cipher suites by default in the long term anyway, but I did not >> disable them in Firefox Nightly yet. In order for it to make sense to >> continue offering Camellia cipher suites long term, we would need to >> improve NSS's support for Camellia to add the ECDHE variants of the >> Camellia cipher suites. Currently, I think the best course of action >> is to let the current configuration ship, then disable Camellia >> support, and eventually add ECDHE_*_WITH_CAMELLIA_* support to NSS, so >> that it is ready in case some problem with AES is found. > > I don't understand the part where you want to disable it. Originally I was very concerned about the TLS ClientHello message size, because we were under the impression that we had to keep it under 256 bytes. That is the reason I prioritized starting this discussion so highly, in fact. But, at IETF88, we learned that there may be another workaround to the interop problems such that we don't have to keep our ClientHello message size under 256 bytes. Still, we shouldn't be wasteful with our ClientHello message size, since we'll always want to keep it under ~1400 bytes for performance and reliability reasons. 1400 bytes might sound like a lot now, but people have already been talking about TLS extensions that could easily eat up the majority of that space. Also, AES implementations are highly optimized, well-audited, well-tested, and are more likely to be side-channel free. Camellia doesn't get used very often. Yet, some websites (most famously, Yahoo!), prefer Camellia over AES, even when we offer AES at higher priority in the handshake. I am not sure how much the performance or existence of lack of side-channel-free implementations of Camellia matter yet. In Firefox, we've kept Camellia enabled for now, and added some telemetry to measure how often each cipher is used, to inform our future decision making here. 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
