On Fri, Mar 28, 2014 at 06:57:34PM +0100, Dr. Stephen Henson wrote:
> Well what goes in each security level is up for discussion and can be changed.
So perhaps session tickets can be allowed at somewhat higher levels?
> 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.
I am concerned that too many naive users will be tempted by the
"sexiness" of "my system security level is higher than yours".
Raising the ceiling on crypto strength is well and good, and tuning
of the cipher-suite order to put adequately stronger stuff ahead
of weaker stuff is all fine, but raising the floor should be done
with great care! The interoperability consequences of floor-raising
can easily defeat the feel-good gains.
Therefore, at the very least the security levels should be documented
with strong warnings about the usability of the resulting configuration
and the potential for *reduced* security overall (connections that
work are more secure, but more and more connections fail entirely).
For most applications, there is only harm in raising the floor
above essential universal peer capabilities. My concern is that
without strong warnings, security levels might do more harm than
good in the hands of people who don't understand the consequences.
> 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).
The practical security of a system does not increase indefinitely
as the security level is raised, rather, beyond reasonably conservative
(in terms of interoperability) levels security decreases as the
system becomes unusable.
> 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.
My concern is that O/S distributions might be very tempted to do
everyone "a favour" and raise the default levels. Just like Debian
broke Exim by raising the floor on DH prime lengths in Exim's
GnuTLS layer from 1024 to 2048.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
