[Ach] Fwd: Re: Inconsistency with handling preferences of Cipherstrings (>=0.9.7m <1.0.0a)

[ianG]

On 13/05/2014 10:12 am, Aaron Zauner wrote:
> FYI
> 
> -------- Original Message --------
> Subject: Re: Inconsistency with handling preferences of Cipherstrings
> (>=0.9.7m <1.0.0a)
> Date: Tue, 13 May 2014 03:57:44 +0000
> From: Viktor Dukhovni <openssl-users at dukhovni.org>
> Reply-To: openssl-dev at openssl.org
> To: openssl-dev at openssl.org
> 
> On Tue, May 13, 2014 at 03:02:21AM +0200, Aaron Zauner wrote:
> 
>>> Can you describe in words what you believe to be the nature of the
>>> "inconsistency" you found?  The semantics of OpenSSL cipherlist
>>> strings definitely changed for the better in 1.0.0, were you
>>> expecting identical results?
>>
>> Yes I was. We have all expected OpenSSL to always prefer DHE based
>> suites if they are possible to negotiate. It seems this is an issue with
>> our cipherstring recommendation for OpenSSL versions <1.0.0 not OpenSSL
>> itself.
> 
> You're also not using the correct primitive cipherlist attribute
> to select DH key exchange.  It is called "kEDH" (recently aliased
> to kDHE, but that's not yet in most releases) not "DHE" or "EDH".
> 
> With OpenSSL 1.0.0, there is also an "EDH", but it is not primitive,
> it is equivalent to "kEDH:!aNULL" (it excludes the anonymous cipher
> suites).  In 0.9.8 there is no "EDH", only kEDH.
> 
> Ditto for EECDH vs kEECDH.
> 
>>>> In particular, given our cipherstring recommendation we encounter that
>>>> DHE and ECDHE based ciphersuites and their preference are neglected by
>>>> these OpenSSL versions [0] - we are currently discussing updating our
>>>> recommendation to an augmented version of this ciphersuite [1].
> 
> One needs to RTFS a lot more closely to create a sensible cipherlist
> that works reasonably well with both 0.9.8 and 1.0.0.  It is
> possible, but requires a bit more attention to detail.
> 
> A problem with explicit cipherlist recommendations is that they
> tend to get deployed in a cargo-cult manner long after they've been
> superceded.  I'd rather see progressive backwards-compatible
> improvements in the DEFAULT and ALL cipherlists in OpenSSL coupled
> with mechanisms such as the new security levels under development
> on the master branch.  I think these will serve users better than
> point-in-time cipherlist tweaks that no two people would make the
> same.
> 
> This is not too say that no users will benefit from various
> recommendations.  Recommend more than selection, each emphasizing
> a slightly different aspect of the space.
> 
>     - Performance at adequate security
>     - Maximal symmetric algorithm + mode security
>     - PFS
>     ...


quick quiz -- what do all the above mean?

Algorithmic agility is a blinky light for developers, not a feature for
users.



iang