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 <k...@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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
