Re: overall sec_param (weakest link) for a gnutls session?

[Alex Elsayed]

Nikos Mavrogiannopoulos wrote:

> On Tue, 2013-12-03 at 17:20 -0500, Daniel Kahn Gillmor wrote:
<snip due to gmane>
>>  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...

Well, one option is to treat it as "cost of best attack." If an attack on 
confidentiality is costed in 'operations/byte disclosed' and an attack on 
integrity is costed as 'operations/successful forgery', the values can 
pretty directly correspond to current academia.

To take RC4 as an illustration, the Royal Holloway attack could be effective 
at 2^24-2^30 connections, and recover 220 bytes. On the CBC side, while 
GnuTLS implements the countermeasures, there's not necessarily a guarantee 
that the _peer_ does; it's therefore worth considering that Lucky13 requires 
approx. 10,000 (~2^13) connections per byte.

However, the CBC attacks should probably be downranked by a.) GnuTLS having 
implemented the countermeasures and b.) possibly a statistical measure of 
how _widely_ peers have deployed the countermeasures. Similarly, the BEAST 
attack could be downranked for both of those reasons, and discounted 
entirely for connections using TLS 1.1 or 1.2.

One thing to keep in mind is that any summary like this will need to change 
over time - as the attacks get better it _must_ take them into account. My 
hope is that explicitly tying it to cost-of-best-attack will make that more 
likely.