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

[Aaron Zauner]

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
    ...

-- 
	Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev at openssl.org
Automated List Manager                           majordomo at openssl.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140513/533d0774/attachment.sig>