<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>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.</p>
<p>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 <strong>today</strong>, so yes I intend to use them if I can find a way. Otherwise, I'll just keep EECDH disabled.</p>
<p>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.</p>
<p>Is there a way to change the curve selection in Dovecot?</p>
<div> </div>
<p>On 2018-12-19 01:49, Tributh via dovecot wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Do you really plan to do this?<br /> RFC 8446 section 9.1:<br /> A TLS-compliant application MUST support key exchange with secp256r1<br /> (NIST P-256) and SHOULD support key exchange with X25519<br /> <br /> I think your idea could be not future proved.<br /> <br /> Beside that, how many mail-clients will remain usable with this cipher<br /> selection?<br /> <br /> Torsten<br /> </div>
</blockquote>
</body></html>