[gnutls-devel] overall sec_param (weakest link) for a gnutls session?

[Nikos Mavrogiannopoulos]

On 01/05/2014 05:57 PM, Matthias-Christian Ott wrote:

>> Hello,
>>  I don't know how practical it is to have priority strings for every
>> possible jurisdiction. We can have though options for the major ones.
> If I'm not mistaken, cipher suites only specify key lengths or symmetric
> ciphers and GnuTLS security parameters are only used for key generation
> not for connections. 

That's partially true. Security parameters are also used to enforce
certain connection parameters as well.

> As Daniel correctly suggested, this is not enough.

Indeed.

> At 30C3 BetterCrypto.org was presented and received some press attention
> in Germany. Looking at their “Applied Crypto Hardening” document, which
> targets system administrators, configuring TLS implementations is still
> too hard and requires too much effort. Most administrators will never
> bother.
> I think we need security profiles for GnuTLS. A security profile covers
> all parameters that are relevant for security including cipher suites,

We have already. This is what the common keywords like NORMAL,
SECURE128, and SECURE192 are. What we don't have is to actively enforce
the certificate verification to the profile level (i.e., make sure the
certificates use algorithms of adequate strength). The reason to keep it
that way was until now that there was no website offering an RSA
certificate with strength equivalent to 128-bits or better.

We could nevertheless, add new security levels such as SECURE80 and
SECURE96 and see how that works out in practice when the levels are
enforced.

I don't know whether I'll have time for that. Anyone wanting to work on
it? Most probably it would require the certificate verification process
to be aware of the security level.

> key lengths and TLS extensions. GnuTLS could include some default
> profiles, such as profiles based on recommendations of institutions like
> NIST or ENISA. 

Are you aware of any such profiles? The only one I know is suiteb from NSA.

> Security profiles are by default loaded from a
> system-wide security profile registry (some directory consists of
> security profile files) according to a system-wide security policy which
> specifies the default profile.

That sounds like a good idea. We could have a priority string like
"SYSTEM:NORMAL" that will use the system profile or NORMAL if nothing
was provided by the system.

regards,
Nikos