X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Hubert Kario
I've been running tests on the openssl 1.1.0 release recently and I've noticed
that if the client doesn't include the supported_groups extension, OpenSSL
will pick curve with id 0x001d, that is ecdh_x25519, as the curve to do ECDHE
over.

While this is not incorrect behaviour according to the standard (it is quite
explicit that if client doesn't provide this extension, server can pick any
curve it wants), I'm afraid that this will cause interoperability problems.

The majority of servers (71%) support *only* prime256v1 curve and of the ones
that default to ECDHE key exchange nearly 83% will also default to this curve.
OpenSSL 1.0.2h also defaults to this curve if there are no curves advertised
by client.

So it is very likely that any client that doesn't advertise curves will expect
the server to select prime256v1. At the same time it is very unlikely that it
will support x25519 (given how new it is).
--
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
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Salz, Rich

> The majority of servers (71%) support *only* prime256v1 curve and of the
> ones that default to ECDHE key exchange nearly 83% will also default to this
> curve.

That's because most people have not moved to OpenSSL 1.1.0 yet.  I'm not joking, I think that's a major reason.

> OpenSSL 1.0.2h also defaults to this curve if there are no curves advertised
> by client.

When I made X25519 the default, I didn't think about it.  That was probably a mistake.  Good catch!
 
> So it is very likely that any client that doesn't advertise curves will expect the
> server to select prime256v1. At the same time it is very unlikely that it will
> support x25519 (given how new it is).

Well the major browsers support it now, so once servers start upgrading to 1.1.0 it will be less of an issue.  But maybe the community thinks the current behavior is a bug?

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Blumenthal, Uri - 0553 - MITLL
On 9/16/16, 11:52, "openssl-dev on behalf of Salz, Rich" <[hidden email] on behalf of [hidden email]> wrote:



>>OpenSSL 1.0.2h also defaults to this curve if there are no curves advertised
>> by client.
>
>When I made X25519 the default, I didn't think about it.  That was probably a mistake.  Good catch!

I think so.

>
>> So it is very likely that any client that doesn't advertise curves will expect the
>> server to select prime256v1. At the same time it is very unlikely that it will
>> support x25519 (given how new it is).
>
>Well the major browsers support it now, so once servers start upgrading to 1.1.0 it will be less of an issue.  But maybe the community thinks the current behavior is a bug?

Yes I think it is a bug, and would like to see this behavior reverted.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Michael Sierchio
In reply to this post by Salz, Rich

On Fri, Sep 16, 2016 at 8:52 AM, Salz, Rich <[hidden email]> wrote:

...

That's because most people have not moved to OpenSSL 1.1.0 yet.  I'm not joking, I think that's a major reason.

Well, you've provided them with a reason. ;-) Srsly, thanks for not making the NIST curves the default.

- M 

--
"Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent man requires only two thousand five hundred."

- The Mahābhārata

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

David Benjamin
When we added X25519 to BoringSSL, we at the same time started made the server require clients supply a curve list (and otherwise we'd just pick a non-ECDHE cipher), because of this issue. That went in back in December 2015 and it's been running just fine. I'd recommend OpenSSL do the same.

Another option is to have separate notions of "most preferred" and "default" curve, but just requiring the curve list is cleaner. That turns out to be practical and aligns well with TLS 1.3. I think if we had to implement the "default" version, we'd probably have treated missing curve list as an advertisement of P-256, so if you prefer the other option, that seems a reasonable implementation strategy.

(I don't have any data on how prevalent such clients are. The issue was noticed during implementation, so we never actually saw the breakage.)

David

On Fri, Sep 16, 2016 at 11:58 AM Michael Sierchio <[hidden email]> wrote:

On Fri, Sep 16, 2016 at 8:52 AM, Salz, Rich <[hidden email]> wrote:

...

That's because most people have not moved to OpenSSL 1.1.0 yet.  I'm not joking, I think that's a major reason.

Well, you've provided them with a reason. ;-) Srsly, thanks for not making the NIST curves the default.

- M 

--
"Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent man requires only two thousand five hundred."

- The Mahābhārata
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Salz, Rich
> When we added X25519 to BoringSSL, we at the same time started made the server require clients supply a curve list (and otherwise we'd just pick a non-ECDHE cipher), because of this issue. That went in back in December 2015 and it's been running just fine. I'd recommend OpenSSL do the same.

In other words:  only use ECDHE if client specifies a curve list.  WFM.


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Viktor Dukhovni
On Sat, Sep 17, 2016 at 02:35:20PM +0000, Salz, Rich wrote:

> > When we added X25519 to BoringSSL, we at the same time started made the
> > server require clients supply a curve list (and otherwise we'd just pick
> > a non-ECDHE cipher), because of this issue. That went in back in December
> > 2015 and it's been running just fine. I'd recommend OpenSSL do the same.
>
> In other words:  only use ECDHE if client specifies a curve list.  WFM.

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.

--
        Viktor.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Salz, Rich
> > In other words:  only use ECDHE if client specifies a curve list.  WFM.
>
> 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.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

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

--
        Viktor.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

David Benjamin
On Sat, Sep 17, 2016 at 12:06 PM Viktor Dukhovni <[hidden email]> 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:

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
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Hubert Kario
In reply to this post by Salz, Rich
On Friday, 16 September 2016 15:52:30 CEST Salz, Rich wrote:

> > The majority of servers (71%) support *only* prime256v1 curve and of the
> > ones that default to ECDHE key exchange nearly 83% will also default to
> > this curve.
>
> That's because most people have not moved to OpenSSL 1.1.0 yet.  I'm not
> joking, I think that's a major reason.
> > OpenSSL 1.0.2h also defaults to this curve if there are no curves
> > advertised by client.
>
> When I made X25519 the default, I didn't think about it.  That was probably
> a mistake.  Good catch!
> > So it is very likely that any client that doesn't advertise curves will
> > expect the server to select prime256v1. At the same time it is very
> > unlikely that it will support x25519 (given how new it is).
>
> Well the major browsers support it now, so once servers start upgrading to
> 1.1.0 it will be less of an issue.  But maybe the community thinks the
> current behavior is a bug?
if client advertised curves, and the curves include stuff besides prime256v1 I
*expect* the other stuff to be negotiated, unless it's smaller than 256 bits,
but it's not what I was talking about

I'm talking only about the case of "no curves advertised at all" i.e.
supported_groups extension missing completely from client hello

--
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
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Hubert Kario
In reply to this post by David Benjamin
On Saturday, 17 September 2016 16:14:02 CEST David Benjamin wrote:

> On Sat, Sep 17, 2016 at 12:06 PM Viktor Dukhovni
> <[hidden email]>
> 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
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: X25519 is the default curve for ECDHE in OpenSSL 1.1.0

Hubert Kario
In reply to this post by Hubert Kario
On Friday, 16 September 2016 17:26:03 CET Hubert Kario wrote:

> I've been running tests on the openssl 1.1.0 release recently and I've
> noticed that if the client doesn't include the supported_groups extension,
> OpenSSL will pick curve with id 0x001d, that is ecdh_x25519, as the curve
> to do ECDHE over.
>
> While this is not incorrect behaviour according to the standard (it is quite
> explicit that if client doesn't provide this extension, server can pick any
> curve it wants), I'm afraid that this will cause interoperability problems.
>
> The majority of servers (71%) support *only* prime256v1 curve and of the
> ones that default to ECDHE key exchange nearly 83% will also default to
> this curve. OpenSSL 1.0.2h also defaults to this curve if there are no
> curves advertised by client.
>
> So it is very likely that any client that doesn't advertise curves will
> expect the server to select prime256v1. At the same time it is very
> unlikely that it will support x25519 (given how new it is).
I've filed a bug on github so that it doesn't fall off the radar...
https://github.com/openssl/openssl/issues/2219

--
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
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment