On Sat, Sep 17, 2016 at 12:06 PM Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
> On Sat, Sep 17, 2016 at 03:46:53PM +0000, Salz, Rich wrote: > > > > If a client offers ECDHE ciphers with no curve list, one might > alternatively just > > > use P-256. It is likely better than the other choices. Most clients > will send a > > > curve list. > > > > Most will, and I'd rather get people off P256 and onto X25519, which is > > why I prefer no ECDHE unless the client sends a curve list. > > I think our responsibility to our users is primarily to provide > the best security we're able, and only secondarily to prod and > nudge them in the direction of progress. > > Offering X25519 and making it preferred over P-256 is compatible > with those priorities. Avoiding ECDHE, and using FFDHE or RSA key > exchange (recall that Chrome, e.g., avoids FFDHE) is not IMHO in > the interest of the users, and so is not I think in ours. > 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: https://www.ssllabs.com/ssltest/clients.html 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. 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. David
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev