[openssl-dev] Circumstances cause CBC often to be preferred over GCM modes

[Nico Williams]

On Tue, Dec 16, 2014 at 09:50:32PM +0100, Hubert Kario wrote:
> > My preference would be: subtract undesired algorithms from a named set,
> > then specify order of preference via some method other than iteratively
> > adding and subtracting algorithms.  Something like:
> > 
> >     DEFAULT:-FOO128:::PFS,AEAD,speed,strength

I would add that this would work like one would expect, and that
speed,strength would give [potentially] different results than
strength,speed, as one would expect.

> Let's say, for the sake of argument, that CBC mode is significantly broken, 
> even in EtM mode (that's another can of worms[1]), then many people will want 
> to prioritise *non-PFS* versions of AEAD ciphers above any other ciphers. And 
> they will want to do it for the same reason people currently leave RC4 in.

Right.  Any crypto is better than no crypto (or, rather, the identity
ciphersuite), but the weak crypto has to go last.  Of course, for
one-offs like this hypothetical one might want a way to indicate that
some algorithms are least preferred and others most, not just sets of
algorithms.

>  1 - by another can of worms I mean: what if it's broken only in MtE
>  mode? how to specify different ciphers depending on presence of this
>  extension, so that in MtE only AEAD ciphers are available while if
>  EtM is on, the list gains CBC ciphers? This is similar to the problem
>  with BEAST: ordering with RC4 at the front for TLS1.0 is sort-of OK,
>  not so much for TLSv1.1 and later...

Specifying ciphersuites and preference on a per-protocol version basis
would help.  Specifying in more context-dependent ways would be nice
but now you'd need a way to name/identify the context.

Nico
--