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
--
_______________________________________________
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
