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

[Julien Vehent]

On 2014-01-02 18:59, ianG wrote:
> On 3/01/14 01:06 AM, Julien Vehent wrote:
>
>
>> 3DES isn't broken.
>
>
> No, but it is end of life.  112bit security for the 2key variant, and an 8 
> byte block makes it just old.  If you've got AES there, use it.  Who hasn't 
> got it?

See https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses
"Internet Explorer uses the cryptographic library “schannel”, which is OS 
dependent. schannel supports AES in Windows Vista, but not in Windows XP."

>
>
>> RC4 is broken, but I am yet to see a practical attack that doesn't
>> require gigabits of traffic.
>
>
> What is a real concern is RC4.  Anything done to move away from that has 
> to be a good thing.  The recent talk by DJB has some real fun descriptions 
> of just how crappy it is becoming.
>
> http://financialcryptography.com/mt/archives/001461.html
>
> The way I read it, trouble starts at 2^24, that's 16M.  By the time you 
> get to 2^30 or 1G it's all over...  Caveat -- I'm working from the graphs 
> described from p49 of the talk, I don't pretend to understand them other 
> than what the pictures say.
>
>
>> Again, this is the tradeoff between what academia thinks is secure, and
>> the level of security
>> users need. It's more important for us to allow Chinese users to
>> download Firefox, than it is
>> to disable RC4 (that westerners almost never use anyway).
>
>
> Hmmm..  Are the Chinese blocked from stronger crypto?
>
>

According to http://www.modern.ie/ie6countdown:
  * 22.2% of China uses IE6
  * 4.9% of users worlwide use IE6

I believe that our jobs, as security professionals, is to provide the best 
security to everyone. Not only to the people that have a better access to 
technology.
This is consistent with Mozilla's mission. So we won't disable old crypto 
algorithms because the security community admits that they are bad. We have 
to live with them.

Again, site owners are free to make their own decisions. This isn't an 
unbreakable rule. At Mozilla, for example, the persona websites are unusable 
with old browsers anyway, so it makes sense to enable stronger TLS on that 
one specifically.

>>>> 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.
>
>
> Java 6 is covered in mud all over, crypto wise.  Maybe time for some nasty 
> words to start circulating.
>
>
>>>> Until all of these clients get fixed, DH params will be limited to
>>>> 1024 bits.
>>> As far as I know stronger DH params are supported by the Java Crypto
>>> Extensions package. That said
>>> it’s usually not deployed anywhere. We’re aware of the issue but
>>> using DH parameters of 1024 bits only
>>> can provide security that is slightly less than 1024bit RSA which can
>>> certainly be factored by large agencies.
>>> - It takes you about 48hours to factor 512bit RSA keys in EC2:
>>> http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf
>>> - The largest Key factored by public research (in a small university
>>> setup!) is currently at 768 bits: http://eprint.iacr.org/2010/006
>>>
>>> We hope that Java will adopt a reasonable security policy in the
>>> future, although I’m personally not conviced that they will.
>
>
> Problem here is that it isn't so much 'Java' it's more the platforms. 
> Android is stuck on Java 6, and the JCE choices aren't even that modern.
>
> http://financialcryptography.com/mt/archives/001450.html
>
> Mac OSX has now bailed from Java directly, so one gets it from Oracle/sun 
> directly, which means Java 7.
>
>
>> For us, it's a choice between DHE with 1024, or no DHE at all. We will
>> not block a subgroup
>> of users because they don't support larger keys. And I suspect no
>> business ever will.
>>
>> So, on DHE vs !DHE, here's the rationale:
>>
>> RSA key rotations happen very rarely in hosting environments. Except
>> when the CA requires it,
>> it's not uncommon to see private keys that are several years old. Keys
>> also move very easily,
>> end up in people's mailboxes or shared folders, or get stored in cloud
>> providers that don't
>> zero their disks after use.
>>
>>  From an operational perspective, the risk of leaking a RSA private key
>> is many times higher than
>> the risk of factoring a DHE key exchange. Even if this key exchange uses
>> half the key size of the
>> RSA key.
>>
>> If an organization wants to spy on Mozilla's DHE traffic, they need to
>> factor *every single key exchange*.
>> On a normal day, that's hundreds of thousands of them. I'm quite certain
>> that the biggest security
>> agencies have clusters than can factor a 1024 DHE key within minutes,
>> but it's still a lot harder
>> and more targeted than factoring one single 2048 RSA key that is used
>> for 5 years.
>>
>> For this reason, we recommend DHE with 1024 bits parameters, and RSA
>> 2048 keys for authentication.
>
>
> I agree with that.
>
>
>>>> 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.
>>> Thanks for reporting this!
>>>
>>> Yes. The intent was to prefer Camellia where possible. First off we
>>> wanted to have more diversity.
>
>
> AS I've argued before, diversity as an argument seems not to survive in 
> the practical world.  But that's something that is contrarian, although it 
> is becoming more mainstream.
>
>
>
>
> iang