On 2013-12-29 18:30, Kurt Roeckx wrote:
On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote:
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.

You might also want to read:
https://bettercrypto.org/

[cc-ing the cert.at mailing list that published this guide]

Thanks for the link! I wasn't aware of this guide.

Overall, I think this guide is great! The configuration examples are very useful. It's also good to have multiple TLS guides with different audiences, so I'm definitely
glad to see more people take on the issue.

I need to do a thorough read of the entire thing. I am a bit puzzled by some of the choices made around their ciphersuite "B" (the most realistic and practical one). Most of the ciphersuite construction sections are still empty, so it's hard to understand what exactly is intended. I did notice a few things that I, personally, find arguable:

Why prefer DHE to ECDHE, when the former is 3 times slower than the later?
There is a bit of a justification in 3.5:
"Since there is much discussion on the security of ECC, flawed settings might very
     well compromise the security of the entire system."
I wish there was references to these "discussions". My understanding of the state of
the art of ECC is that P-256 is considered at least as secure as DH and RSA.

They recommend AES-128 in "3.4. Keylengths", but publish a ciphersuite that prefers AES-256 (see below). This is probably just an oversight, the guide is still in "Draft".

The guide is not backward compatible with all clients. We, at Mozilla, must maintain backward compatibility with even the oldest, most broken, clients on the internet, and this shapes our guidelines. For example, the ciphersuite B doesn't contain 3DES or RC4, and is therefore unusable on *a lot* of PC that still run Windows XP. I wish we could just remove these two ciphers, but it's not a realistic goal in the near future.

Same goes for the recommendation to use DH parameters > 1024 bits. We tried using a 2048 bits parameter a few months back. We first noticed a big spike in CPU usage, caused by the largest exponentiation, but that was still acceptable. What forced the rollback is the long list of java 6 clients that broke, because they don't accept DH keys > 1024 bits. Until all of these clients get fixed, DH params will be limited to 1024 bits.

I *think* they want to prefer CAMELLIA to AES, judging by the published ciphersuite. But the construction must be wrong because it returns AES first. If the intent is to
prefer Camellia, then I am most interesting in the rationale.

ECDSA is explicitely discarded. It doesn't hurt to have it enabled, and makes the ciphersuite portable to systems that prefer ECDSA certicates (granted, it's not that many...).

$ openssl ciphers -v 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'|column -t DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

--
Julien Vehent
OpSec @ Mozilla
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to