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