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

[Nikos Mavrogiannopoulos]

On Tue, 2013-12-03 at 17:20 -0500, 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".

Hello Daniel,
 That's something I've spent quite some time thinking at. I believe it
is a nice idea, and doable, but it is not an easy mapping. That is there
are few factors:
1. Confidentiality
What level of confidentiality does this ciphersuite offer? (depends on
the cipher, the key exchange, and the certificates)

2. Tampering
What level of tamper-resistance this ciphersuite offers? (depends on the
HMAC used).

Since for (2) only online attacks are a concern one could tolerate
algorithms that have a lower security margin (e.g., HMAC-MD5) than their
confidentiality counter-parts (e.g., AES-128).

To make things worse, in the DH key exchange, the client can only
presume the security level, as he cannot know, whether the prime sent by
the server is of some weak form. 

Nevertheless, despite the difficulties, I think it would be very good to
have an estimator of the security of the overall session.

> 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?

To be complete it should, but you can start without it.

>  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?

I think it would be good to keep it simple and refer only to the current
session and not any previous ones.

>  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?

I guess so. For such an indicator all parameters should come into play.
However, in that case the question is "is LEGACY but client
authenticated better than NORMAL but without client authentication?". I
don't have an answer for that :)

>  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.
You could have a function that reports the overall level, and another
that reports the level per section (KX,CERT,MAC ...) - or one function
combining everything.

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

Since we have all the known counter-measures implemented that would be
pretty much ok, but I see your point. More important issue would be how
to rate RC4...

regards,
Nikos