<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Sep 17, 2016 at 12:06 PM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Sep 17, 2016 at 03:46:53PM +0000, Salz, Rich wrote:<br class="gmail_msg">
<br class="gmail_msg">
> > If a client offers ECDHE ciphers with no curve list, one might alternatively just<br class="gmail_msg">
> > use P-256.  It is likely better than the other choices.  Most clients will send a<br class="gmail_msg">
> > curve list.<br class="gmail_msg">
><br class="gmail_msg">
> Most will, and I'd rather get people off P256 and onto X25519, which is<br class="gmail_msg">
> why I prefer no ECDHE unless the client sends a  curve list.<br class="gmail_msg">
<br class="gmail_msg">
I think our responsibility to our users is primarily to provide<br class="gmail_msg">
the best security we're able, and only secondarily to prod and<br class="gmail_msg">
nudge them in the direction of progress.<br class="gmail_msg">
<br class="gmail_msg">
Offering X25519 and making it preferred over P-256 is compatible<br class="gmail_msg">
with those priorities.  Avoiding ECDHE, and using FFDHE or RSA key<br class="gmail_msg">
exchange (recall that Chrome, e.g., avoids FFDHE) is not IMHO in<br class="gmail_msg">
the interest of the users, and so is not I think in ours.<br class="gmail_msg"></blockquote><div><br></div><div>Chrome always sends the curve list, so it not using DHE isn't really relevant here. Unless I missed one (there's a lot), client listed here either sends the curve list or doesn't support EC at all:</div><div><a href="https://www.ssllabs.com/ssltest/clients.html">https://www.ssllabs.com/ssltest/clients.html</a><br></div><div><br></div><div>Any special-case here will also need to be dismantled or made more complex come TLS 1.3 where the curve/group list is required for (EC)DH-based key agreement. It was honestly a mistake for RFC 4492 to be omitted.</div><div><br></div><div>In fact, a similar mistake in TLS 1.2 (omitted sigalgs implies SHA-1) actually cost OpenSSL a bug---PR 3560 would have been noticed since the handshake wouldn't have worked---which, in turn, cost the ecosystem. It will take much much longer to stop accepting SHA-1-signed ServerKeyExchange messages in TLS 1.2 because of this. TLS 1.3 fixes this too and forbids omitting sigalgs.</div><div><br></div><div>David</div></div></div>