------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1415
Phil Pennock <pdp@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Phil Pennock <pdp@???> 2013-11-18 20:01:20 ---
No. Sorry, I wish we could, but that's not realistic.
For clarity, we're talking about the _defaults_ here, since any administrator
can use the `tls_dh_max_bits` setting in their Exim configuration file to raise
the limit, to any integer value they like. This option is fully documented.
It's the only place that a limit of 2236 exists in the Exim source code.
The NSS issues were encountered, by me, while coding, with real deployed code.
You can see my name in the mozilla bug you reference (citing the keylength.com
recommendations). A lot of the text posted by Janne Snabb came from me when we
were debugging the issue together. That was a year and a half ago.
The DHE parameter sizes are not negotiated, which means this is a *hard* break
for any clients which are not fixed. It takes much longer than a year and a
half for fixes to become sufficiently deployed that server operators no longer
need to worry about them.
If you want stronger security with a fallback for older clients, I *Strongly*
suggest that you look at the ECDHE cipher-suites, for PFS using ECC. You'll
need this for the MX port.
You can raise the limit for classic DHE but I don't recommend doing so on the
MX port, because you'll lower security. Clients which can't handle that size
will fail to negotiate TLS and then retry without TLS in use.
Fortunately, most of the problems known are from NSS, which tends to be used in
GUI apps, so you mostly only need to worry about the Submission port.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
