On Mon, Nov 18, 2013 at 08:03:00AM -0700, LuKreme wrote:
> > I changed smtpd_tls_dh1024_param_file to use a 2k dh key at the mx server.
> > That solved the problem ...
>
> I can't imagine that that didn't cause other problems. If a server
> negotiates for a dh1024 key and is expecting a dh1024 key and it
> gets a dh2048 key, it is (hopefully) going to pitch a fit and barf.
There is no negotiation for a DH 1024 prime. TLS clients announce
support for various prime-DH cipher-suites with an *unspecified*
prime size. The TLS server announces the prime unilaterally in
its Server Key Exchange message when it chooses such a cipher-suite
from the client's list.
Based on TLS protocol standards alone, all primes are equal, but
clearly some primes are more equal than others. Some clients want
primes that are not too large, others primes that are not too small.
So the server needs a "Goldilocks prime". :-)
The bit-length of a "Goldilocks prime" varies by application
protocol, based on the capabilities of the client implementations
of that application protocol. For MTA to MTA SMTP, we have some
evidence that 2048-bits is "just right", for MUA to MTA submission,
1024-bits is for now more appropriate.
--
Viktor.
