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

[Viktor Dukhovni]

On Tue, Dec 16, 2014 at 11:55:37AM -0600, Nico Williams wrote:

> Internally using such numeric strength assignments is fine.
> 
> In particular I want you to avoid the problem that Cyrus SASL had (and
> still has) with the "security strength factor (SSF)", where entire
> security mechanisms get boiled down to a single numeric strength factor
> even though a mechanism might negotiate cryptographic algorithms, and
> where applications end up hardcoding SSF values for things like Kerberos
> V5 (which has "SSF" of 56, because initially Kerberos V5 only supported
> 1DES).  This is a horrible problem to have.

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.

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.

-- 
	Viktor.