My opinion is that security by RFC is not security, it's mommy medicine.  Standards have had a terrible time keeping up with security realities.

NITS's curves leak side channel information all over the place.  I don't have details on what implementations are set to calculate the NIST curves in constant time, and that's not an easy feat to do anyway so I don't want to depend on implementations that say they are actually doing it the right way.  Frankly I can't be bothered to keep up with that.  There are better curves today, so yes I intend to use them if I can find a way.  Otherwise, I'll just keep EECDH disabled.

I have EDH now, and I've not yet run into a client that doesn't support it.  I want EECDH, but I won't use it without safe curves.  I'm confident that EECDH with safe curves and a second choice of EDH will support any clients that are worth using.  OpenSSL supports X25519, and that is half the battle.

Is there a way to change the curve selection in Dovecot?

On 2018-12-19 01:49, Tributh via dovecot wrote:

Do you really plan to do this?
RFC 8446 section 9.1:
   A TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519

I think your idea could be not future proved.

Beside that, how many mail-clients will remain usable with this cipher
selection?

Torsten