Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

[Yoav Nir <[e-mail]>]

On Sep 23, 2013, at 7:37 AM, Patrick Pelletier <[e-mail]> wrote:

> On 9/21/13 9:00 PM, Yoav Nir wrote:
> 
>> There's also Apache, the most common web server on the web, that doesn't have configuration parameters for EDH key lengths, and tells OpenSSL to use 1024 bits.
> 
> I view the Apache situation as an entirely different thing, since it's on the server side, rather than the client side, and the server is the one who gets to choose the parameters in the first place.  If the BCP says "you should configure your server to use 2048 bits" and the server only supports 1024 bits, then the sysadmin will just configure it to use 1024 bits, and we'll be no worse off than if the BCP had said to use 1024 bits.  The point is that this doesn't actually break anything.

Some people are suggesting that clients break the connection if offered a 1024-bit group. It does make sense that they would break the connection if offered, say, a 512-bit group, no?

> This is in contrast to the situation where the server picks 2048 bits, and the *client* only supports 1024 bits.  In that case, the handshake will fail.  So I see the Java (client side) issue as much worse than the Apache (server side) issue.
> 
> Also, of course, this is easy to fix, since one can recompile Apache to support larger DH:
> 
> http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html
> 
> (Hey, this isn't any worse than suggesting that everyone on Red Hat needs to recompile to get ECC support.)

No, it's different asking a vendor to change something vs asking end users to recompile Apache.

> It's also worth pointing out that technically this is an issue with mod_ssl, not with Apache itself.  You could always use mod_gnutls instead.

You can, but then hardly anyone does.

Yoav