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

[Viktor Dukhovni]

On Tue, Dec 16, 2014 at 12:43:13PM -0600, Nico Williams 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
> 
> (Whatever is in DEFAULT minus FOO128, sort by PFS, AEAD, speed,
> strength.)

I agree that iterative add/subtract reording is not for most mortals,
however, the above is worse.  Absolute preference for PFS regardless
of key length seems unwise.  Do you *really* want:

    ADH-DES-CBC-SHA         SSLv3 Kx=DH       Au=None Enc=DES(56)   Mac=SHA1

ahead of a non-PFS AES-256?  The effective strength MUST come first,
but there need to be a few ways to squash "strong-enough" 128/256
ciphers so that other factors can dominate.

One way to do that is to set an upper-bound on the effective bit
length "MAXEFECTIVE=128", so that nothing is considered stronger
than 128, and then other factors come into play. Thus @SPEED would
sort fastest first which combined with an "@STENGTH" capped at 128,
gives a sensible outcome for those wanting an adequate, but performant
128-bit outcome, with AEAD first, ...

And the browsers should implement SHA-384, and why the hell are we
using SHA-384 with AES256-GCM instead of SHA-256 anyway?  Surely
the SHA256 HMAC construction has adequate strength in this context?

-- 
	Viktor.