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
----- Original Message -----
From: "Aaron Zauner" azet@azet.org To: security@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).
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
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
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
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-to-...
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
security@lists.fedoraproject.org
-
Aaron Zauner -
Hubert Kario -
Nikos Mavrogiannopoulos