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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
