On Fri, Mar 28, 2014, Viktor Dukhovni wrote: > On Fri, Mar 28, 2014 at 05:57:42PM +0100, Dr. Stephen Henson wrote: > > > > In the new Fedora we will try system-wide configuration parameters for > > > all crypto libraries (patch [0] was along that line), so such a change > > > is very good news. It would be nice if that branch was public for > > > comments or so, but otherwise, it would be ideal if such parameters > > > could be set using a cipher string. > > > > > > > Early version added to the master branch. Still needs some work but should > > give the general idea. What is included at each level should be considered > > provisional and subject to change. > > Are we about to repeat the GunTLS breakage with client DH parameter > size constraints in OpenSSL? DH parameter sizes are not negotiated > in TLS, and enforcing aggressive lower bounds in TLS clients causes > more harm than good. Clients that insist on NIST SP-800 consistent > sizes above 1024 for DH primes are broken. Please do not go there, > at least for security levels intended to be usable defaults for the > public Internet (I think this includes at least levels 0, 1 and 2). > > Also, excluding RC4-SHA1 at security level 2, makes that level > unusable on today's Internet. Is that really warranted? > > Why are session tickets disabled at security level 3 (128-bit)? > RFC 5077 strongly suggests using AES128 for session tickets. Are > there a lot of servers whose session tickets are expected to be > using weaker algorithms? Session tickets improve performance of > applications that connect and disconnect frequently, and make it > practical to employ more expensive strong PKI operations for the > full handshake, by ammortizing the cost via connection reuse. Why > disable session tickets? >
Well what goes in each security level is up for discussion and can be changed. As you note level 2 and higher general will have problems with "today's internet". Not just the RC4-SHA1 issue but also the fact that SHA1 for digital signatures only offers 80 bits of equivalent security. The whole point of the framework is to make it easier to use parameters consistent with a security level instead of requiring applications (or users) to set multiple different parameters (supported signature algorithms, cipher suites, curves). Applications aren't compelled to use the framework. They can set the security level to zero (either with an API call of the cipher string) and perform their own checks or provide a customised callback. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
