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

[Julien Vehent]

On 2014-01-02 17:12, Ryan Sleevi wrote:
> On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote:
>>  Hi Aaron,
>>
>>  On 2014-01-02 16:10, Aaron Zauner wrote:
>> > Hi Kurt,
>> >
>> > On 02 Jan 2014, at 21:51, Kurt Roeckx <kurt at roeckx.be> wrote:
>> >
>> >> On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:
>> >>>> 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. Second not everybody
>> >>> is running a sandybridge (or newer) processor. Camellia has better
>> >>> performance for non-intel processors with about the
>> >>> same security.
>>
>>  I would argue that our documents target server configurations, where
>>  AES-NI is now a standard.
>
> I would have to disagree here. The two largest users of NSS, by *any*
> measure, are Firefox and Chromium, both of which use it as a client.
> Further, the notion of "server" configurations is further muddied by
> efforts such as WebRTC, which sees a traditional "client" (eg:
> heterogeneous configurations and architectures) acting as both a DTLS
> client and a DTLS server.
>
> NSS in server mode is so full of sharp edges and so few code examples that
> I'd strongly discourage it being used as the reference for what NSS
> "SHOULD" do.
>

Sorry for the confusion. By "our documents", I meant:
* https://wiki.mozilla.org/Security/Server_Side_TLS
* https://bettercrypto.org/

And not NSS in client mode.

Your point about WebRTC making the client a server is interesting though.
Which ciphers preferences will the server use ?

>>
>> >
>> > What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec.
>> > Team by the way?
>>
>>  There are 5 security teams at Mozilla, so Mozilla Sec Team is a very
>>  large group.
>>  I think we all want a new stream cipher in TLS to replace RC4. But
>>  that's going
>>  to take years, and won't help the millions of people who don't replace
>>  their software
>>  that often.
>
> Really? If anything, Firefox and Chromium have shown that new changes can
> be deployed on the order of weeks-to-months, and with server opt-in (such
> as NPN/ALPN), the majority of *users* traffic can be protected or enhanced
> within a few weeks-to-months after.
>
> Google already has deployed experimental support, for example. Likewise,
> the adoption of SPDY - within Firefox and within a number of significant
> web properties - show that it's significantly quicker than it used to be
> to protect users.
>
> You're correct that there's going to be a long-tail of sites that don't
> update, sure, but rapid deployment is certainly an increasing possibility
> for the majority of users.
>

There is the case of old clients that don't upgrade, and the case of 
servers.

The reality on the server side isn't that bright, I'm afraid. Upgrading
server components is still slow and difficult. I've been trying to find
commercial systems that support the full blend of TLS features, and failed.

Chances are that even if new ciphers make it into TLS1.3, they won't be
widely deployed in any production environment for another 3 to 5 years.
After all, TLS 1.2 was standardized in 2008, and we're just starting to see 
it.

>>
>>   From an Operations Security point of view, the question is: how do we
>>  provide the
>>  best security possible, with the cards we currently have in our hands,
>>  and without
>>  discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in the
>>  short term.
>>
>>  - Julien
>
> I strongly, vehemently disagree with that conclusion. Solutions like
> ChaCha20/Poly1305 are able to reach a broad spectrum of users near
> immediately and ubiquitously, providing meaningful security and speed
> improvements to users. If the idea is that no solution is a good solution
> until it's a ubiquitous solution, well, that's just silly and not
> reflective of the world we live in at all.
>

That is not what I meant. I simply wanted to point out that, on the 
operational
side, changes and improvements are *a lot* slower to propagate.
Even if ChaCha2020/Poly1305 are deployed in Firefox and Chrome tomorrow, we 
won't
have them on the server side for a while. And when we do, there will still 
be a lot
of users who don't use it. Look at the percentage of users who negotiate 
ECDHE with
AES-GCM, for example.

Don't get me wrong: it's a critical improvement to make. But in the 
meantime,
we still need to find the best security trade offs for the remaining 80%. 
And, sadly,
for some people, that means using RC4 or 3DES.

- Julien