----- Original Message ----- > From: "Aaron Zauner" <azet@xxxxxxxx> > To: security@xxxxxxxxxxxxxxxxxxxxxxx > 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 -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
