[Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

Julien Vehent julien at linuxwall.info
Thu Jan 2 18:09:07 CET 2014


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



More information about the Ach mailing list