On Sat, Sep 17, 2016 at 12:06 PM Viktor Dukhovni <openssl-us...@dukhovni.org>

> 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:

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.

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to