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