On Sun, Dec 15, 2013 at 8:46 AM, Kurt Roeckx <k...@roeckx.be> wrote:

> But some people are also considering disabling it by default,
> as I think all other where talking in this thread, not just
> reduce the preference.
>
> > For the same reason, the server ciphersuite that we recommend at
> > https://wiki.mozilla.org/Security/Server_Side_TLS
> > does not drop Camellia, but lists it at the bottom of the ciphersuite.
> > It's a safe choice, but not one that we recommend.
>
> As far as I know the reasons for not recommending it are:
> - It's slower
> - It probably doesn't have much constant-time implementations.
>
> So as I understand it, the reason for not recommending it don't
> have anything to do with the security of Camellia itself.
>

Because of unfortunate design choices, Camellia is (along with AES)
difficult to implement in constant time with high performance. That *is* a
serious fault in the algorithm. AES-NI is a workaround for AES, but no such
workaround exists for Camellia. In addition, Firefox supporting Camellia
while other browsers don't is bad for interoperability. Finally, other
browsers have demonstrated that Camellia isn't needed for web
compatibility, so removing support for Camellia means we can avoid
maintaining Camellia.

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 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.

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

Reply via email to