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

[Matthias-Christian Ott]

On 2013-12-03 23:20, Daniel Kahn Gillmor wrote:
> I find myself wishing that GnuTLS could report a "weakest link security
> level summary" for an established session.  I know this is generally a
> gross oversimplification, but i think many library users actually want
> simplifications, so we should give them to them.
> 
> So, for example, if you used a server-side RSA key of 4096 bits (HIGH),
> with AES-256 (HIGH), and ECDHE with CURVE-SECP192R1 (LEGACY), it would
> report "LEGACY".

I wonder whether LEGACY and NORMAL are good categories. I think the
actual security levels need some more thinking. Unfortunately I don't
have good answers either.

> I'm thinking this would be useful for programs that want to ensure all
> of the knobs are turned at least to a certain level, or perhaps to
> behave differently if the knobs are *not* set to a certain level (as
> opposed to just refusing to communicate).
> 
> For example, i can imagine a MTA (acting as a server) that will respond
> differently to an "RCPT TO: secureaccount at example.org" depending on
> whether the "weakest link" of the connection is "NORMAL" or higher.  I
> could also imagine a web application that chooses to display different
> data depending on the security level selected (e.g. a warning box that
> says "we are allowing this connection, but you really should upgrade
> your client").
>
> This information is currently extractable from things like
> gnutls_dh_get_prime_bits, etc, but the user needs to know a lot about
> TLS to figure out how to extract the various pieces of information and
> compare them against each other.  And as new ciphersuites and new modes
> are introduced into GnuTLS, library users might miss out on some
> relevant details, so it seems like it would be better to have this
> summary feature in the library itself, for users who *want* a gross
> simplification without having to get into the details themselves.

In mod_gnutls, mod_ssl and nginx, you could implement this as a library
that reads environment variables of the request (e.g. SSL_CIPHER in
mod_gnutls and mod_ssl) and computes the security from this – no patches
for TLS libraries required. For other types of software this could be
implemented as a separate library as well.

> What do folks think about this idea?

+1

Businesses with regulatory requirements that must use a certain set of
cryptography algorithms or must ensure a minimal key length etc. could
also make use of this.

> Open questions:
> 
>  0) should this summary include things like the size of the intermediate
>     or root CAs, or the digest algorithms used in those certificates?

Depends on if the software uses Trust On First Use, Certificate Pinning,
Certificate Notaries etc. which make CAs less important.

>  1) how do we track something like this across TLS renegotiation?  if a
>     session starts off with a weakest link of LEGACY, and then
>     renegotiates to NORMAL, is the current session "NORMAL"?  or would
>     we consider it LEGACY because the original connection was LEGACY?

Can you give an example of an implementation with this behaviour? I
vaguely remember that SChannel on Windows 7 and Internet Explorer 9 had
some problems when experimented with GnuTLS and ECDH and ECDSA only
cipher suites (it pretended to know only 3DES and RSA or something like
this).

>  2) when uncommon mechanisms come into play, if they are the "weakest
>     link" (e.g. when an otherwise "HIGH" session encounters a "LEGACY"
>     client-side cert), should this summary info drop accordingly?

Yes, the overall security is just as good as its weakest link.

>  3) i can imagine some frustration from users if they find out that the
>     summary is lower than they want but they don't know how to identify
>     the weak link itself.  Should such a sec_param summary also indicate
>     which parts of the connection are at the weakest sec_param level?  I
>     can imagine a bitfield that indicates
>     KX|SERVERKEY|CERTSIG|MAC|CIPHER|etc, which would be returned along
>     with the sec_param, so that users who wanted to know which part of
>     the negotiated parameters ought to be improved, but i don't know how
>     to enumerate that.

Tt's not clear to me whether you mean developers using GnuTLS or
“end-users”. End-users probably need more practical advice like “You are
using an oudated version of web browser/application XY that is not
secure by todays standards. Thus you can only access limited
information. Please upgrade to version A.B to gain full access”. This
definitely doesn't belong in a TLS library.

>  4) i'm not sure how to properly represent qualitative shifts like
>     cipher block chaining modes in this analysis -- at the moment, i'm
>     just imagining that AES-256-CBC would be rated the same level as
>     AES-256-GCM based on key size strength, even though i know that's
>     not really the accepted wisdom at the moment.  Some of these
>     decisions will likely be judgement calls, but i think it's worth
>     baking a set of reasonable judgement calls based on our current
>     knowledge into the library for users who don't want to have to learn
>     how to make those calls themselves.  In the event that knowledge
>     changes, we can push out a modified version of these judgement calls
>     in an upgrade, rather than requiring all of our users to update
>     their code or configurations.

You could make this a rule-based system with a separate rule set so that
users can adapt to their needs and receive automatic updates for
standard rule sets. Some thinking needs to be done on howto generate
proper error messages for end-users with existing rule engines.

Is your focus on web sites and applications (seems easier) or on all
software which uses TLS?

Regards,
Matthias-Christian