[openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0

[Hubert Kario]

On Saturday, 17 September 2016 16:14:02 CEST David Benjamin wrote:
> On Sat, Sep 17, 2016 at 12:06 PM Viktor Dukhovni
> <openssl-users at 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

but there may be clients that used similar logic to not advertise DHE 
ciphers...

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

yes, those were mistakes on part of specifications (probably to allow people 
not to implement extensions properly for at least "just a wee bit longer"), 
but it is in specifications,  and it is essentially set in stone by already 
deployed implementations

any kind of departure from this behaviour is likely to cause interoperability 
failures (and they will be blamed on OpenSSL as it was the last thing that 
changed...)

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160919/426de2ee/attachment.sig>