Hi Aaron,
Two things I'd like to mention before I reply:
1. I think it's great to have two guides with divergent points of view.
I'm mostly
interested in discussing design choices, because these discussions
are useful.
I'm not interested in convincing the ACH group that one
recommendation is better
than the other, since it completely depends on the context.
2. My experience as a web hosting engineer, and sysadmin, has convinced
me that
building security recommendations on what academia thinks alone is
very dangerous.
Security doesn't live in a bubble. It depends on people and systems.
It must
protect an activity, but never ever block it entirely.
That being said, I put my comments below.
On 2014-01-02 15:33, Aaron Zauner wrote:
On 02 Jan 2014, at 18:09, Julien Vehent <jul...@linuxwall.info>
wrote:
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)
I will bail here. My understanding of the mathematics of ECC isn't
sufficient to make
a strong decisions. Others at Mozilla, Google and major organizations
have decided
to implement ECC, and we trust their decision.
From my end, the decision to prefer ECC to DHE in Mozilla's guidelines
is performance oriented.
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.
Aside from performance, timing attacks are apparently easier in
AES-256.
https://groups.google.com/forum/#!msg/mozilla.dev.tech.crypto/36na1B2brGU/xUMMPMgkmEMJ
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.
3DES isn't broken.
RC4 is broken, but I am yet to see a practical attack that doesn't
require gigabits of traffic.
Again, this is the tradeoff between what academia thinks is secure, and
the level of security
users need. It's more important for us to allow Chinese users to
download Firefox, than it is
to disable RC4 (that westerners almost never use anyway).
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.
For us, it's a choice between DHE with 1024, or no DHE at all. We will
not block a subgroup
of users because they don't support larger keys. And I suspect no
business ever will.
So, on DHE vs !DHE, here's the rationale:
RSA key rotations happen very rarely in hosting environments. Except
when the CA requires it,
it's not uncommon to see private keys that are several years old. Keys
also move very easily,
end up in people's mailboxes or shared folders, or get stored in cloud
providers that don't
zero their disks after use.
From an operational perspective, the risk of leaking a RSA private key
is many times higher than
the risk of factoring a DHE key exchange. Even if this key exchange
uses half the key size of the
RSA key.
If an organization wants to spy on Mozilla's DHE traffic, they need to
factor *every single key exchange*.
On a normal day, that's hundreds of thousands of them. I'm quite
certain that the biggest security
agencies have clusters than can factor a 1024 DHE key within minutes,
but it's still a lot harder
and more targeted than factoring one single 2048 RSA key that is used
for 5 years.
For this reason, we recommend DHE with 1024 bits parameters, and RSA
2048 keys for authentication.
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 and Poly1305 MAC to TLS. It’s already
implemented in Chrome. It’ll provide for better security
with lower performance overhead and more diversity for users with
non-Intel processors.
http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00
Is there a good reason not to prefer Camellia over AES? The issue is,
if it’s not prefered it won’t get used in any type of
machine as it’s set up because all clients will end up using AES due
to the way the ciphersuite is implemented.
ECDSA is explicitely discarded. It doesn't hurt to have it enabled,
and makes the
ciphersuite portable to systems that prefer ECDSA certicates
(granted, it's not that many…).
Agreed. And we will as soon as a TLS standard supports other Curves
as well. Don’t get me wrong; ECC is a cool thing and very
good for security with relatively low performance overhead as
compared to RSA - But it’s also quite new in terms of implementation
in libraries and security audits. With the research I refered to
above I’d feel more safe to remove ECDSA for now.
Thanks,
Aaron
- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
