On Sun, Sep 01, 2013 at 07:02:00PM -0400, Wietse Venema wrote:
> I will keep my anaswer short.
>
> First, the primary mission of Postfix is to deliver mail, not to
> force someone into adopting a particular world view. I have asked
> Viktor what patch would restore interoperability.
>
> Second, we have to be mindful that Postfix and Exim are not the
> only MTAs in existence. If placating Exim results in the loss of
> interoperability with other MTAs, then we may have to reconsider
> our approach.
I don't think there is anything obivously correct that Postfix can
do. It seems most likely that the issue is in GnuTLS, assuming
the original user report is correct. It is I think not right for
GnuTLS client software to introduce an aggressive default minimum
value on peer server DH primes. Since the group size is not
negotiated any such limits just break interoperability.
We could perhaps argue that this is a TLS specification bug, since
there is no mechanism for the client and server to agree on a
suitable group, but that's not terribly productive. The server
chooses a group, that choice should be reasonable and the client
needs to accept that choice.
One thing that Postfix could do is always return a 2048-bit group
when OpenSSL asks for 1024-bits (i.e. *not export*). This would
be at a non-trivial performance penalty, but SMTP server connection
rates are orders of magnitude lower than HTTP server connection
rates, so arguably, the cost is acceptable. What we don't know is
which client implementations will break because 2048 is too big!
This problem has just now been reported for the first time, perhaps
because someone updated GnuTLS to a recent version that exhibits
this behaviour. I think the right place for the fix is in GnuTLS
or applications that use it.
Another possible Postfix work-around is to disable prime EDH
altogether, leaving just EECDH, but this is a bit severe. With
any luck, there are as yet very few Exim sites impacted by this,
and ideally they can take appropriate steps (tune GnuTLS to allow
1024-bit MODP DH groups).
--
Viktor.
