[Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox
ryan-mozdevtechcrypto at sleevi.com
Thu Jan 2 23:12:47 CET 2014
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
> > 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
More information about the Ach