On Fri, Sep 27, 2013 at 11:23:27AM -0400, Phillip Hallam-Baker wrote: > Actually, it turns out that the problem is that the client croaks if the > server tries to use a key size that is bigger than it can handle. Which > means that there is no practical way to address it server side within the > current specs.
Or smaller (e.g. GnuTLS minimum client-side EDH strength). And given that with EDH there is as yet no TLS extension that allows the client to advertise the range of supported EDH key lengths ( with EECDH the client can communicate supported curves), there is no timely incremental path to stronger EDH parameters. In addition to the protocol obstacles we also have API obstacles, since the protocol values need to be communicated to applications that provide appropriate parameters for the selected strength (EDH or EECDH). In OpenSSL 1.0.2 there is apparently a new interface for server-side EECDH curve selection that takes client capabilities into account. For EDH there is need for an appropriate new extension, and new interfaces to pass the parameters to the server application. Deploying more capable software will take a O(10 years). We could perhaps get there a bit faster, if the toolkits selected from a fixed set of suitable parameters and did not require application changes, but this has the drawback of juicier targets for cryptanalysis. So multiple things need to be done: - For now enable 1024-bit EDH with different parameters at each server, changed from time to time. Avoid non-interoperable parameter choices, that is counter-productive. - Publish a new TLS extension that allows clients to publish supported EDH parameter sizes. Extend TLS toolkit APIs to expose this range to the server application. Upgrade toolkit client software to advertise the supported EDH parameter range. - Enable EECDH with secp256r1 (and friends) unless it is reasonably believed to be cooked for efficient DLP by its creators. - Standardize new EECDH curves (e.g. DJB's Curve1174). -- Viktor. P. S. For SMTP transport security deploy DNSSEC and DANE TLSA. I'm hoping at least one of the larger service providers will do this in the not too distant future. Postfix (2.11 official release 2.11) will support this in early 2014. Exim will take a bit longer, as they're cutting a release now, and the DANE support is not yet there. The other MTAs will I hope follow along in due course. The SMTP backbone (inter-domain SMTP via MX records, ...) can be upgraded to use downgrade-resistant authenticated TLS. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography