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-Google-Talk-td29703.html > > 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 mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
