> From: owner-openssl-us...@openssl.org On Behalf Of Viktor Dukhovni > Sent: Sunday, 01 September, 2013 15:24
> In: > > http://archives.neohapsis.com/archives/postfix/2013-09/0003.html > > Peer Heinlein reports that some Exim SMTP clients fail to establish > a TLS session with Postfix SMTP servers because Exim enforces a > minimum prime size of 2048-bits for MODP EDH. My reply in: > > http://archives.neohapsis.com/archives/postfix/2013-09/0015.html > > boils down the behaviour of SSL_CTX_set_tmp_dh_callback(3) which > invokes the application callback with one of two keylengths: > > #define SSL_EXPORT_PKEYLENGTH(a) (SSL_IS_EXPORT40(a) ? 512 : 1024) > > in response to which Postfix returns parameters with a 512-bit or > a 1024-bit prime. > Aside: In addition to head, that value is in all releases I have back many years, except I think fips. > - 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. > Given the high computational cost of prime EDH, my guess is that > it does not make much sense to go beyond 1024-bits, and that EECDH > is by far the better choice for greater security. > Aside: OpenSSL 0.9.8 does support ECDHE (and anon and fixed) suites, but not by default; you have to tweak the cipher-string (which hope posftix can do, but don't know) or rebuild (always technically possible, but probably undesirable for users). RedHat is presumably still an issue there. > 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? > Clearly nothing 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? > 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. > It would be nice to have more documentation for the EC side of the > interface. > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
