On Tue, Sep 03, 2013 at 03:16:06PM +0200, Dr. Stephen Henson wrote:
> > Incidentally, I just noticed the undocumented
> > SSL_CTX_set_tmp_ecdh_callback(), which has the same interface as
> > SSL_CTX_set_tmp_dh_callback(3) and it seems is also called with
> > keylength equal to either 512 or 1024. What is the meaning of
> > the keylength in this context?
>
> The keylength parameter and indeed is pretty useless (it was just copied from
> the DH version) the best it can be used for is to determine if the ciphersuite
> is export or not.
And since there are no EECDH export ciphersuites:
$ openssl ciphers -v 'kEECDH:!HIGH:!MEDIUM:!eNULL'
140735189950940:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no
cipher match:ssl_lib.c:1314:
even that information is not particularly useful.
> > I have been using the equally undocumented SSL_CTX_set_tmp_ecdh(),
> > which just sets a fixed curve for all EECDH cipher-suites. Is there
> > any disadvantage to this approach?
>
> Just setting P-256 should be fine for most circumstances just about everything
> supports it. The only thing it will cause problems with is SuiteB and 192 bit
> security mode but you really need (unreleased) OpenSSL 1.0.2 or later to
> handle
> SuiteB properly.
The Postfix user (that is email administrator) interface does not
require users to know much or anything at all about the various EECDH
curves. The administrator chooses one of:
# default "strong"
smtpd_tls_eecdh_grade = none | strong | ultra
and behind the scenes Postfix TLS library parameters with defaults
that only expert users would ever consider changing set:
tls_eecdh_strong_curve = prime256v1
tls_eecdh_ultra_curve = secp384r1
> For OpenSSL 1.0.2 the EC curve negotiation has been overhauled. Both client
> and server can set curve preferences and by calling:
>
> SSL_CTX_set_ecdh_auto(ctx, 1);
>
> the curve to use is handled automatically.
That sounds like a substantial improvement. However, I notice that
this too is undocumented. :-( In the Postfix project the rule is
that undocumented code does not get included even in snapshot
releases. (Think of these as commits of working code to the master
repository). Such a policy is long overdue in the OpenSSL project.
Should there also be an SSL_CTX_set_dh_auto(ctx, 1)? With suitable
compiled-in MODP groups (perhaps from RFC 5114, though there is I
think no gain from the DSA-style subgroups in TLS since "q" is not
sent to the client).
On Tue, Sep 03, 2013 at 01:40:29AM -0400, Dave Thompson wrote:
> > - Is it reasonable for clients to expect stronger EDH groups?
> >
> > - Is there is any API support in OpenSSL for servers to provide a
> > suitable range of parameters, perhaps tied to the negotiated symmetric
> > algorithm key size? (With anonymous cipher-suites there is no public
> > key on which to base the EDH parameter choice).
>
> Not that I've seen. The callback does get the SSL *, from which
> it could find the suite, and its characteristics.
>
> It isn't an IETF standard, but NIST SP800-57 has a general
> purpose mapping of strength across symmetric, hash, RSA (IFC),
> DSA/DH (IDL), and ECC which I would use for lack of any better.
Right, and this is what the GnuTLS folks seem to have used to
(inadvisably) set EDH prime lower bounds on TLS clients, thereby
breaking interoperability with pretty much every other TLS
implementation.
So the question is what to do now? Should every application using
GnuTLS work-around the problem? Should other implementations
(OpenSSL, ...) now rush to implement SP800-57 compatible EDH
parameters based on the negotiated symmetric key length?
> > I have been using the equally undocumented SSL_CTX_set_tmp_ecdh(),
> > which just sets a fixed curve for all EECDH cipher-suites. Is there
> > any disadvantage to this approach?
>
> In principle if a client supports some curve(s) but not the one
> you selected, handshake will unnecessarily skip ECDHE -- and
> if no other key-exchange available fail. I'd say in practice if
> you pick p-256 or maybe p-384 you probably get decent results.
That was my conclusion when EECDH support was added to Postfix 2.6
snapshots in 2008. In Postfix 2.8 EECDH was enabled by default.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
