4:58 p.m.
Hi List,
The levels and their current settings:
=====LEGACY=====
A level that may include algorithms with known weaknesses (but not
completely broken) which will ensure maximum compatibility with legacy
systems. It should provide at least 64-bit security and include RC4, but
not MD5 as signature algorithm.
MACs: MD5, SHA1+
Curves: All supported
Signature algorithms: must use SHA-1 hash or better
Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC, RC4
Key exchange: ECDHE, RSA, DHE
DH params size: 768+
RSA params size: 768+
SSL Protocols: All supported (SSL3.0+)
You do state 'but not completely
broken' - 768bit/param RSA/DH can
nowadays be broken in reasonable time (and money) even by private
individuals. As far as I know it is the largest key-length to be
factored by an university research project (!). They do not always use
the best hardware available for such tasks (I currently work as an HPC
engineer in my day job), and I can imagine that Amazon AWS instances
might sometimes even perform better than some university setups. There's
even a ready-to-factor setup for AWS provided by Nadia Heninger:
http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf
https://www.cis.upenn.edu/~nadiah/projects/faas/
=====DEFAULT======
A reasonable default for today's standards. For F21 it should provide
80-bit security and no broken ciphers like RC4.
MACs: SHA1+
Curves: All supported
Signature algorithms: must use SHA-1 hash or better
Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC
Key exchange: ECDHE, RSA, DHE
DH params size: 1024+
RSA params size: 1024+
SSL Protocols: All supported (SSL3.0+)
I'd remove SSLv3, there's really no
reason to keep it in there, you'll
be backwards compatible to OpenSSL releases dating back to the early
2000s. SSLv3 has various protocol flaws.
All larger web companies I know of and security people are nowadays
using 2048bit keys since 1024bit is too close to a real world (for
nation-state actors, that is) factorable quantity. Is there any reason
not to bump that up a notch?
=====FUTURE======
A level that will provide security on a conservative level that is
believed to withstand any near-term future attacks. That will be
an 128-bit security level, without including protocols with known
attacks available (e.g. SSL 3.0/TLS 1.0). This level may prevent
communication with commonly used systems that provide weaker security
levels (e.g., systems that use SHA-1 as signature algorithm).
MACs: SHA1+
Curves: All supported
Signature algorithms: must use SHA-256 hash or better
Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC
Key exchange: ECDHE, RSA, DHE
DH params size: 2048+
RSA params size: 2048+
SSL Protocols: TLS1.1+
Algorithm choices seem very reasonable. One must be careful
not to allow
TLS <1.1 though (BEAST). Possible additions would be ChaCha20, Poly1305
and Ed25519. I'd actually go with TLS1.2+ and 4096bit RSA/DH. It's the
future, right? Is there any reason not to (e.g. performance)?
Sincerely,
Aaron
6:51 a.m.
New subject: available crypto policies
----- Original Message -----
From: "Aaron Zauner" <azet(a)azet.org>
To: security(a)lists.fedoraproject.org
Sent: Wednesday, 2 April, 2014 11:58:30 PM
Subject: Re: available crypto policies
Hi List,
> The levels and their current settings:
>
> =====LEGACY=====
> A level that may include algorithms with known weaknesses (but not
> completely broken) which will ensure maximum compatibility with legacy
> systems. It should provide at least 64-bit security and include RC4, but
> not MD5 as signature algorithm.
>
> MACs: MD5, SHA1+
> Curves: All supported
> Signature algorithms: must use SHA-1 hash or better
> Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC, RC4
> Key exchange: ECDHE, RSA, DHE
> DH params size: 768+
> RSA params size: 768+
> SSL Protocols: All supported (SSL3.0+)
You do state 'but not completely broken' - 768bit/param RSA/DH can
nowadays be broken in reasonable time (and money) even by private
individuals. As far as I know it is the largest key-length to be
factored by an university research project (!). They do not always use
the best hardware available for such tasks (I currently work as an HPC
engineer in my day job), and I can imagine that Amazon AWS instances
might sometimes even perform better than some university setups. There's
even a ready-to-factor setup for AWS provided by Nadia Heninger:
http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf
https://www.cis.upenn.edu/~nadiah/projects/faas/
I don't disagree, but it does require a targeted attack. And targeted
not at server but at the specific user. This is unlikely. As such it does
provide security against opportunistic eavesdropper.
There's still over 800 servers in the Alexa top 1M that use 768 bit DH:
https://jve.linuxwall.info/blog/index.php?post/TLS_Survey
This is also not supposed to be the default but requiring action by
the administrator to change to.
> =====DEFAULT======
> A reasonable default for today's standards. For F21 it should provide
> 80-bit security and no broken ciphers like RC4.
>
> MACs: SHA1+
> Curves: All supported
> Signature algorithms: must use SHA-1 hash or better
> Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC
> Key exchange: ECDHE, RSA, DHE
> DH params size: 1024+
> RSA params size: 1024+
> SSL Protocols: All supported (SSL3.0+)
I'd remove SSLv3, there's really no reason to keep it in there, you'll
be backwards compatible to OpenSSL releases dating back to the early
2000s. SSLv3 has various protocol flaws.
Windows 2003 is still supported and it doesn't support SSLv3 in default
configuration. The same TLS Survey found over 4000 servers that support
only SSLv3.
Most of those protocol flaws apply to TLSv1.0 too, and we certainly
can't disallow it.
All larger web companies I know of and security people are nowadays
using 2048bit keys since 1024bit is too close to a real world (for
nation-state actors, that is) factorable quantity. Is there any reason
not to bump that up a notch?
Default is usable only as long is it works for majority of users.
There is still a lot of web servers that use 1024bit RSA out there,
not to mention 1024bit DH which is the only option for admins
running Apache 2.2 or not running the relatively new Apache 2.4.7+
It also matches the security of SHA-1 signatures. Again, we
certainly can't disallow SHA-1 in the default configuration.
> =====FUTURE======
> A level that will provide security on a conservative level that is
> believed to withstand any near-term future attacks. That will be
> an 128-bit security level, without including protocols with known
> attacks available (e.g. SSL 3.0/TLS 1.0). This level may prevent
> communication with commonly used systems that provide weaker security
> levels (e.g., systems that use SHA-1 as signature algorithm).
>
> MACs: SHA1+
> Curves: All supported
> Signature algorithms: must use SHA-256 hash or better
> Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC
> Key exchange: ECDHE, RSA, DHE
> DH params size: 2048+
> RSA params size: 2048+
> SSL Protocols: TLS1.1+
Possible additions would be ChaCha20, Poly1305
and Ed25519.
+1. The idea is that we want ciphers that provides around
128 bit *effective* security. So they do qualify once they are
accepted as standard.
I'd actually go with TLS1.2+ and 4096bit RSA/DH. It's the
future, right? Is there any reason not to (e.g. performance)?
It's the future in the sense of "tomorrow", not as in "next
year".
IOW, current best practice.
We already bumped it to 3072 bit for RSA and DH to match
the 128 bit level of the rest of parameters. There is no
reason to increase it to 4096bit (and the negative side
is performance).
--
Regards,
Hubert Kario
BaseOS QE Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
7:51 p.m.
New subject: available crypto policies
Hi Hubert,
Hubert Kario wrote:
I don't disagree, but it does require a targeted attack. And
targeted
not at server but at the specific user. This is unlikely. As such it does
provide security against opportunistic eavesdropper.
Well. We've seen a couple
of directed, active attack schemes being
leaked over the last 9 months. Even going as far as beating service
providers in terms of latency at exchange points. Sure, it's not
feasible to do this wholesale, still it is cause for concern, I guess.
There's still over 800 servers in the Alexa top 1M that use 768
bit DH:
https://jve.linuxwall.info/blog/index.php?post/TLS_Survey
This is also not supposed to be the default but requiring action by
the administrator to change to.
People might deploy this, e.g. because of lack of
understanding. :/
Windows 2003 is still supported and it doesn't support SSLv3 in
default
configuration. The same TLS Survey found over 4000 servers that support
only SSLv3.
Most of those protocol flaws apply to TLSv1.0 too, and we certainly
can't disallow it.
Sadly, this is true. Point taken.
Default is usable only as long is it works for majority of users.
There is still a lot of web servers that use 1024bit RSA out there,
not to mention 1024bit DH which is the only option for admins
running Apache 2.2 or not running the relatively new Apache 2.4.7+
It also matches the security of SHA-1 signatures. Again, we
certainly can't disallow SHA-1 in the default configuration.
I've
overlooked SHA-1 in there. This is correct.
The thing is, you might want to force administrators to deploy "newer"
and stronger cryptography, if you have the chance to, right? Still
referring to old standards as "DEFAULT" might not be the best idea, this
was the point I was trying to make and still am. These policies might be
deployed for a long time in servers (which often do not get upgraded on
a regular basis).
+1. The idea is that we want ciphers that provides around
128 bit *effective* security. So they do qualify once they are
accepted as standard.
I do hope they will be. Another thing would be Ed25519.
> I'd actually go with TLS1.2+ and 4096bit RSA/DH. It's
the
> future, right? Is there any reason not to (e.g. performance)?
It's the future in the sense of "tomorrow", not as in "next
year".
IOW, current best practice.
Shouldn't the current best practice be default
instead of a setting
marked "FUTURE"?
General question: What will be the lifespan of these recommendations,
and if they're adopted in for example RHEL: how often will they be adapted?
Thanks,
Aaron
2:52 a.m.
New subject: available crypto policies
On Wed, 2014-04-02 at 23:58 +0200, Aaron Zauner wrote:
Hi List,
Hello,
Hubert was faster, but here are some additional comments.
> MACs: MD5, SHA1+
> Curves: All supported
> Signature algorithms: must use SHA-1 hash or better
> Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC, RC4
> Key exchange: ECDHE, RSA, DHE
> DH params size: 768+
> RSA params size: 768+
> SSL Protocols: All supported (SSL3.0+)
You do state 'but not completely broken' - 768bit/param RSA/DH can
nowadays be broken in reasonable time (and money) even by private
individuals.
I know, but there must be a level in order to connect to servers that
offer these parameters. Servers offering such parameters are not so
rare:
http://gnupg.10057.n7.nabble.com/gnutls-devel-GnuTLS-3-1-7-can-t-connect-...
> MACs: SHA1+
> Curves: All supported
> Signature algorithms: must use SHA-1 hash or better
> Ciphers: AES-GCM, AES-CBC, CAMELLIA-GCM, CAMELLIA-CBC, 3DES-CBC
> Key exchange: ECDHE, RSA, DHE
> DH params size: 1024+
> RSA params size: 1024+
> SSL Protocols: All supported (SSL3.0+)
I'd remove SSLv3, there's really no reason to keep it in there, you'll
be backwards compatible to OpenSSL releases dating back to the early
2000s. SSLv3 has various protocol flaws.
All larger web companies I know of and security people are nowadays
using 2048bit keys since 1024bit is too close to a real world (for
nation-state actors, that is) factorable quantity. Is there any reason
not to bump that up a notch?
The default level must be compatible with the current internet,
otherwise people will be reducing the default level to legacy (note that
security as a need comes after usability).
Algorithm choices seem very reasonable. One must be careful not to
allow
TLS <1.1 though (BEAST). Possible additions would be ChaCha20, Poly1305
and Ed25519. I'd actually go with TLS1.2+ and 4096bit RSA/DH. It's the
future, right? Is there any reason not to (e.g. performance)?
I've only listed the algorithms that are currently defined for TLS. When
this policy is extended for other protocols, or for new algorithms being
defined, these - and others that offer security at a comparable level -
can be added.
regards,
Nikos
2:58 a.m.
New subject: available crypto policies
On Fri, 2014-04-04 at 02:51 +0200, Aaron Zauner wrote:
>> I'd actually go with TLS1.2+ and 4096bit RSA/DH.
It's the
>> future, right? Is there any reason not to (e.g. performance)?
>
> It's the future in the sense of "tomorrow", not as in "next
year".
>
> IOW, current best practice.
Shouldn't the current best practice be default instead of a setting
marked "FUTURE"?
Well, that's the current known best practice, but not the current best
deployment practice. We cannot have a default that is not compatible
with the majority of the existing deployments. If we do that, we will
not actually improve anything other than force the users to switch from
the default to the weaker level.
General question: What will be the lifespan of these
recommendations,
and if they're adopted in for example RHEL: how often will they be adapted?
You mean the mappings of the three defined levels? These will be adapted
per release if required. The defaults of the previous releases will also
be available as settings.
regards,
Nikos
5:07 a.m.
New subject: available crypto policies
Hi,
Nikos Mavrogiannopoulos wrote:
Well, that's the current known best practice, but not the current
best
deployment practice. We cannot have a default that is not compatible
with the majority of the existing deployments. If we do that, we will
not actually improve anything other than force the users to switch from
the default to the weaker level.
Ok.
You mean the mappings of the three defined levels? These will be
adapted
per release if required. The defaults of the previous releases will also
be available as settings.
Sounds good!
Aaron
3685
days inactive
3687
days old
security@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Aaron Zauner -
Hubert Kario -
Nikos Mavrogiannopoulos