[gnutls-devel] what should be the actual security level of SECURE128?

[Tim Ruehsen]

On Monday 10 February 2014 10:07:11 Nikos Mavrogiannopoulos wrote:
> On Fri, Feb 7, 2014 at 3:50 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> >> So the question is what should we do in gnutls. Make SECURE128 just a
> >> string that provides better security than NORMAL, or enforce the 128-bit
> >> level when this string is specified? The latter will have quite some
> >> implications as a lot of software seems to specify SECURE128 as the
> >> default priority string for no particular reason (and often with no way
> >> to change it). Any ideas?
> > 
> > As I understood, SECURE128 right now combines two different things, which
> > in the docs (http://gnutls.org/manual/html_node/Priority-Strings.html)
> > are named as
> > 1) message authenticity security level
> > 2) security level (i guess that means 'data encryption security level')
> > You could add new keywords for 1) e.g. AUTH128 etc.
> > Old software (recompiled or not) could still work with newer libraries.
> > Adapted software will/can check for newer libraries available (at compile
> > and/or run time) and may use the set of keywords at will.
> 
> Hello,
>  The idea is to add a 3rd level as:
> 3) certificate verification level (i.e., signature check)
> 
> Adding a new initial keyword with the additional level it would make
> it unaccessible to any of the software that use the SECURE128 and
> SECURE256 keywords. I'd like even old software to take advantage from
> new protection methods as time goes by and a new gnutls library is
> available.
> 
> > Another option would be to have a new function to enable the new behavior
> > at run-time.
> > Maybe with some kind of non-fatal warning during handshake if the function
> > hasn't been called and SECURE128 has been given without AUTH...?
> 
> As you suggest breaking old software isn't really reasonable, so what
> I am thinking is to set very conservative security levels for
> SECURE128 (the same as normal) for the 3rd option, and in a few years,
> when SHA256 or better are widely used in certificates, we could
> increase it. Of couse the ones who'd like to take advantage of the
> better verification profiles could set them directly using the
> %PROFILE additional keywords.

That seems nearly exactly what i tried to say in my first suggestion (the 
obvious, 'natural' choice). Maybe I just wanted to say that, but fucked it up 
somehow ;-)

Regards, Tim