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

[Daniel Kahn Gillmor]

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'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.

What do folks think about this idea?

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?

 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?

 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?

 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.

 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.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: </pipermail/attachments/20131203/2fbe5b19/attachment.sig>