Hi Julien,
I took the liberty to answer a few of your questions (in CC to dev-tech-crypto
and ach). Others might want to add something as well:
On 02 Jan 2014, at 18:09, Julien Vehent jul...@linuxwall.info wrote:
Overall, I think this guide is great! The configuration examples are very
useful.
It's also good to have multiple TLS guides with different audiences, so I'm
definitely
glad to see more people take on the issue.
Thank you.
Why prefer DHE to ECDHE, when the former is 3 times slower than the later?
There is a bit of a justification in 3.5:
Since there is much discussion on the security of ECC, flawed settings
might very
well compromise the security of the entire system.
I wish there was references to these discussions. My understanding of the
state of
the art of ECC is that P-256 is considered at least as secure as DH and RSA.
Well, no. Bernstein and Lange have been auditing NIST/SECG and other
standardized curves that are
currently implemented in crypto libraries over the last years. They may be
considered secure against
the ECDLP (some) but other issues remain that caused us to prefer DHe over
ECDHe.
We’re aware of the performance implications - the paper in general tries to
cope with best performance
and backwards compatability, but not at the cost of security. I’m aware that
this philosophy might differ
to that of the Mozilla Security Team. Recent publications have prompted some
change in mindset though
and one cannot recommend a security guide that takes all factors into
consideration at the potential cost
of (side channel) attacks or downgrade attacks.
Please take the time to read up on:
- http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf
- http://safecurves.cr.yp.to/
-
http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters
(There’s also interesting research to Koblitz curves in the reply by thomas
pornin)
They recommend AES-128 in 3.4. Keylengths, but publish a ciphersuite that
prefers
AES-256 (see below). This is probably just an oversight, the guide is still
in Draft”.
Our viewpoint was that if possible, take a stronger cipher. We’re aware that
people might want
to change this in their configuration if performance is paramount. We probably
should discuss this again.
The guide is not backward compatible with all clients. We, at Mozilla, must
maintain
backward compatibility with even the oldest, most broken, clients on the
internet, and
this shapes our guidelines. For example, the ciphersuite B doesn't contain
3DES or RC4,
and is therefore unusable on *a lot* of PC that still run Windows XP. I wish
we could
just remove these two ciphers, but it's not a realistic goal in the near
future.
I personally think this is the wrong descision. I’m aware that you want to
cater to as many clients as possible,
but you also want to ship a solid and secure product. What people see and care
about when they surf from
XP machines using RC4 or 3DES is this nice green padlock in the browser bar.
What they actually get as
security are ciphers that have been considered insecure in academia for now
over 15 years.
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.
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.
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. We hope the IETF TLS-WG will chose to adopt the proposal by Adam
Langley of Google to include the
ChaCha20 stream cipher
