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

[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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [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
> 
> wrote:
> > On Sat, Sep 17, 2016 at 03:46:53PM +, 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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario]

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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 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 
wrote:

> On Sat, Sep 17, 2016 at 03:46:53PM +, 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

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

[Viktor Dukhovni]

On Sat, Sep 17, 2016 at 03:46:53PM +, 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

Re: [openssl-dev] 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

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

[Viktor Dukhovni]

On Sat, Sep 17, 2016 at 02:35:20PM +, 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

Re: [openssl-dev] 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

Re: [openssl-dev] 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" 
 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.

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Michael Sierchio]

On Fri, Sep 16, 2016 at 8:52 AM, Salz, Rich  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

Re: [openssl-dev] 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