On Sun, Dec 15, 2013 at 09:50:04PM -0800, Brian Smith wrote: > > so removing support for Camellia means we can avoid maintaining Camellia.
I was under the impression that you wanted to keep it in NSS, just not enabled by default. I can perfectly understand that, I'm neither in favour or against changing that default. But I think removing support for it is a step too far, since we might at some point need it. > Like I've said before, for any cipher that we support TLS_RSA_* for, we > should be supporting some TLS_ECDHE_* variants, so that we don't make > servers choose between the cipher they need/want to use and ephemeral key > exchange. So, to keep Camellia support, we'd need to implement and enable > the TLS_ECDHE_* variants. But, it doesn't seem worth the effort when it > doesn't seem to improve interoperability, performance, or security. I'm not sure how hard adding an ECDHE version is, but I can't imagine it being that hard. > I think instead we are better off spending resources on making AES-GCM > constant-time(-ish) and on adding support for ChaCha20+Poly1304. Google > already has constant-time (I think) ChaCha20+Poly1304 patches for NSS and > there's also been progress on constant-time(-ish) GHASH implementations for > NSS. Note that ChaCha20+Poly1304, by design, is straightforward to > implement in a high-speed, constant-time fashion. ChaCha20+Poly1305 (not 1304) looks very promising, but I'm not sure how much research has gone into ChaCha20. It seems like a good candidate, since the related Salsa20 at least has had some research. But I wouldn't remove Camellia until at least something like ChaCha20+Poly1305 has been used for a while. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
