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