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

[Nico Williams]

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

(Whatever is in DEFAULT minus FOO128, sort by PFS, AEAD, speed,
strength.)

Preferences should affect the order in which cipher suites are
advertised/picked, not which ones are advertised.

Algorithms that are not desired should not be advertised/used.

Nico
--