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

[Hubert Kario]

On Tuesday 16 December 2014 12:43:13 Nico Williams wrote:
> On Tue, Dec 16, 2014 at 06:26:50PM +0000, Viktor Dukhovni wrote:
> > Internally OpenSSL has a multi-dimensional property matrix, and
> > preferences between numerically equal ciphers are based on other
> > properties.  The (stable) numeric sorting just re-arranges blocks
> > of ciphers already sorted by other means.  Thus preference for PFS
> > already puts kEECDH and kDHE ahead of kRSA for otherwise equally
> > strong ciphers.
> > 
> > When the user choose a group of ciphers to add to a cipherlist,
> > the members of the group retain their relative order.  However,
> > 
> > there are interesting games that can be played with:
> > 	aRSA:-kRSA:ALL:@STRENGTH
> > 	
> > 	(prefers kRSA over PFS).
> > 
> > which perturb the order, because the most recenly removed elements
> > end up at the top of the list when "ALL" is added.  So the relative
> > preferences of various properties can be changed.
> 
> Iterating subtaction and addition seems like a fragile way to indicate
> preference.
> 
> > The SASL problem mostly does not bite OpenSSL,  However, @STRENGTH
> > (which is often needed) is not sufficiently tunable, it is not eas
> > to prefer AES-128 with AEAD over 256 with CBC.  For that we need
> > some new mappings that produce slight different "effective" stengths.
> 
> 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
> 

The more I think about it, the more I like it.

BTW: the way the sorting is currently implemented, it would just be a question 
of defining (in addition to currently present @STRENGTH) @PFS, @AEAD, @SPEED 
sorting orders (maybe also @STRENGTH128 which explicitly assumes any effective 
key size above 128 is 128).

That's because if there's one thing I don't like about my proposal from few 
months back, is that we essentially have to define one "true" order of 
importance, say which is more important: speed, pfs or AEAD.

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.

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

-- 
Regards,
Hubert Kario