Hi
On 02/05/2014 16:29, Remi Gacogne wrote:
Hi Lukas,
The default value for max-dh-param-size is set to 1024, thus keeping
the current behavior by default. Setting a higher value (for example
2048 with a 2048 bits RSA/DSA server key) allows an easy upgrade
to stronger ephemeral DH keys (and back if needed).
Please note that Sander used 4096bit - which is why he saw huge CPE load.
Imho we can default max-dh-param-size to 2048bit.
I am afraid upgrading DH key size from 1024 bits to 2048 bits can divide
performance by 2 for CPU-bound installations doing mostly DHE key
exchanges, based on some quick benchmarks I ran. Of course it depends on
the ratio of new SSL/TLS connections using DHE (without resumption) you
get, but I think it may too big of an impact to change the default
without warnings.
Following on from previous comments, I agree that compatibility with old
versions is not a bad idea in the immediate future and agree that
keeping the default of 1024bit is acceptable for the short term.
However, two things spring to mind
1) we should be encouraging stronger cipher use and longer key use. As
such, we should possibly indicate that the next major release will
default to the DH keysize relating to the certificate key size so that
maximum security is enabled by default.
2) we should be doing everything we can to have the options for users to
enable maximum security. Settings such as the max-dh-param-size option
are great as it allows users to configure the level of security they
desire. We should be adopting all the security options we can, even if
the defaults are off or are of lower strength to limit performance
impact in the short term. Those users with high security requirements
can then choose to make their security stronger and accept the hit of
the increased load and reduced performance.
For too long, we have had products defaulting to unconfigurable, low
security options - things like the static DH key length of 1024bit
options within Apache and HAproxy where they were not fully
configurable. Some of these products are used for a "long" time before
being upgraded and need to be coded to deal with future security
requirements where ever possible - even if those security levels seem
"absurd" today.
Thanks for this patch - I look forward to testing it in the not too
distant future.
Kind regards,
Mike
