[gnutls-devel] overall sec_param (weakest link) for a gnutls session?
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Dec 3 23:20:24 CET 2013
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
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
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?
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 965 bytes
Desc: not available
More information about the Gnutls-devel