Re: OpenSSL prime EDH parameters
On Tue, Sep 03, 2013, Viktor Dukhovni wrote: > > To the specific point in your reply, does OpenSSL actually support > DSA-style groups (with p, g and q) where DH groups are expected? > For example can such groups be returned from the temp DH callback? > Certainly the dhparam(1) command does not seem to support groups > with "q" values. > Support in OpenSSL 1.0.2 and later for X9.42 DH parameters (which include q) will be more complete. For previous versions the length parameter in the PKCS#3 DH parameter structure can be set by converting DSA parameters to DH using (for example) the -dsaparam option to the dhparam utility. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL prime EDH parameters
On Tue, Sep 03, 2013 at 04:53:52PM +0200, Dr. Stephen Henson wrote: > The SSL_CONF_cmd interface in OpenSSL 1.0.2 and later might be > useful too. It's designed to provide a common format for configuration. Thanks, I'll take a look at that when I get a chance. [ I'm still concerned about the DANE support in 1.0.2 by the way, it should IMHO be dropped or fixed, neither seems to be happening. ] > It was documented on my hard disk, I just forgot to push it, oops. It's > included in commit c3eb33763bf2999843fe4124f3f39dea6edc26e6 Thanks. Any chance that documenting new interfaces will become a requirement for code contributions to OpenSSL? > > 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). > > There is some gain server side during key generation, but nothing client side. The more important part of the question (than speed-ups, ...) is whether OpenSSL should use a more complex DH group selection strategy than just "export" vs "not export"? Namely, should OpenSSL servers choose DH parameters with strength commensurate to the symmetric key size? What would be the performance implications (would this require DSA-style groups to be practical or is that still too costly with larger primes). Should the GnuTLS developers be left to solve the mess they've created, or is it time to consider moving in the direction they've all-too-boldly embarked upon? To the specific point in your reply, does OpenSSL actually support DSA-style groups (with p, g and q) where DH groups are expected? For example can such groups be returned from the temp DH callback? Certainly the dhparam(1) command does not seem to support groups with "q" values. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL prime EDH parameters
On Tue, Sep 03, 2013, Viktor Dukhovni wrote: > On Tue, Sep 03, 2013 at 03:16:06PM +0200, Dr. Stephen Henson wrote: > > 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 > The SSL_CONF_cmd interface in OpenSSL 1.0.2 and later might be useful too. It's designed to provide a common format for configuration. > > 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. :-( > It was documented on my hard disk, I just forgot to push it, oops. It's included in commit c3eb33763bf2999843fe4124f3f39dea6edc26e6 > 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). > There is some gain server side during key generation, but nothing client side. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL prime EDH parameters
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL prime EDH parameters
On Sun, Sep 01, 2013, Viktor Dukhovni 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. > 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. 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. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL prime EDH parameters: postfix
> 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL prime EDH parameters
On Sun, Sep 01, 2013 at 07:24:24PM +, Viktor Dukhovni wrote:
> 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.
On a related note, this is a problem with GnuTLS pushing the envelope
too aggressively. Since the TLS protocol does not support negotiation
of the DH parameters between client and server, client enforcement
of strong DH parameters that exceed common practice is rather
unwise. Before TLS clients start being pedantic about key lengths
in auxiliary algorithms, most server implementations need to be
updated to implement said key lengths with corresponding SSL
cipher-suites.
Looking at the source code of GnuTLS 3.2.4 (really master branch
from "git" which is 3.2.4 plus some new code) I see that with GnuTLS
priority strings the "Normal" security level defaults to a minimum
DH bit length of 2432, which is perhaps sound cryptography, but poor
engineering:
typedef struct
{
const char *name;
gnutls_sec_param_t sec_param;
unsigned int bits; /* security level */
unsigned int pk_bits; /* DH, RSA, SRP */
unsigned int dsa_bits; /* bits for DSA. Handled differently
since
* choice of key size in DSA is political.
*/
unsigned int subgroup_bits;/* subgroup bits */
unsigned int ecc_bits; /* bits for ECC keys */
} gnutls_sec_params_entry;
static const gnutls_sec_params_entry sec_params[] = {
{"Insecure", GNUTLS_SEC_PARAM_INSECURE, 0, 0, 0, 0, 0},
{"Export", GNUTLS_SEC_PARAM_EXPORT, 42, 512, 0, 0, 0},
{"Very weak", GNUTLS_SEC_PARAM_VERY_WEAK, 64, 727, 0, 0, 0},
{"Weak", GNUTLS_SEC_PARAM_WEAK, 72, 1008, 1024, 160, 160},
{"Low", GNUTLS_SEC_PARAM_LOW, 80, 1248, 2048, 160, 160},
{"Legacy", GNUTLS_SEC_PARAM_LEGACY, 96, 1776, 2048, 192, 192},
{"Normal", GNUTLS_SEC_PARAM_NORMAL, 112, 2432, 3072, 224, 224},
{"High", GNUTLS_SEC_PARAM_HIGH, 128, 3248, 3072, 256, 256},
{"Ultra", GNUTLS_SEC_PARAM_ULTRA, 256, 15424, 3072, 512, 512},
{NULL, 0, 0, 0, 0, 0}
};
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
