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

[Ryan Sleevi]

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.

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

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

>  --
>  dev-tech-crypto mailing list
>  dev-tech-crypto at lists.mozilla.org
>  https://lists.mozilla.org/listinfo/dev-tech-crypto