Re: [openssl-project] 1.1.1a milestone status

2018-11-12 Thread Matt Caswell



On 08/11/2018 13:21, Matt Caswell wrote:
> There are currently 5 PRs and 1 issue with the 1.1.1a milestone set
> against them.
> 
> Of the 5 PRs, 3 are in the ready state:
> 
> 7462: Test: link drbgtest statically against libcrypto
> 7437: rand_unix.c: open random devices on first use only
> 7391: Unbreak SECLEVEL 3 regression causing it to not accept any ciphers.
> 
> 2 PRs are still in review:
> 7442: Don't negotiate TLSv1.3 if our EC cert isn't TLSv1.3 capable
> 7503: Separate ca_names handling for client and server
> 
> The one 1.1.1a issue (7419) will be closed as soon as 7437 gets pushed.
> 
> It would be great if we could get the 3 PRs that are ready pushed, and
> the other 2 reviewed in the next day or two to enable us to do a release
> soon.

We're now at 3 outstanding PRs - 2 of which are in the "ready" state. The only
other outstanding one is:

7596: Fix rpath-related Linux "test_shlibload" failure.

Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] OpenSSL Security Advisory

2018-11-12 Thread Matt Caswell
OpenSSL Security Advisory [12 November 2018]


Microarchitecture timing vulnerability in ECC scalar multiplication 
(CVE-2018-5407)
===

Severity: Low

OpenSSL ECC scalar multiplication, used in e.g. ECDSA and ECDH, has been shown
to be vulnerable to a microarchitecture timing side channel attack. An attacker
with sufficient access to mount local timing attacks during ECDSA signature
generation could recover the private key.

This issue does not impact OpenSSL 1.1.1 and is already fixed in the latest
version of OpenSSL 1.1.0 (1.1.0i). OpenSSL 1.0.2 is affected but due to the low
severity of this issue we are not creating a new release at this time. The 1.0.2
mitigation for this issue can be found in commit b18162a7c.

OpenSSL 1.1.0 users should upgrade to 1.1.0i.

This issue was reported to OpenSSL on 26th October 2018 by Alejandro Cabrera
Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and Nicola Tuveri.

Note


OpenSSL 1.1.0 is currently only receiving security updates. Support for this
version will end on 11th September 2019. Users of this version should upgrade to
OpenSSL 1.1.1.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20181112.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html



signature.asc
Description: OpenPGP digital signature
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] QUIC, again

2018-11-12 Thread Benjamin Kaduk
Between last time we discussed it and now, waiting seems to have been
prudent, as the TLS/QUIC interaction got significantly revamped.
The current QUIC drafts have TLS exporting key material and plaintext
handshake messages, with QUIC record protection used on the wire and not
TLS record protection.  There is a huge amount of interest in QUIC at the
IETF, and we will need to support it eventually.  But that may be best as
limited to exposing the needed APIs and not necessarily pulling in a full
QUIC implementation -- I haven't thought about that question very much.

I don't think I would have the team as a whole prioritize QUIC over FIPS,
though it may be worth someone taking an initial look at what would be
needed.

-Ben

On Mon, Nov 12, 2018 at 11:34:20AM +0100, Richard Levitte wrote:
> For those wanting to follow what's happening in QUIC space, this is a
> good place to start: https://datatracker.ietf.org/wg/quic/about/
> 
> In message <20181112.113323.260349601387601601.levi...@openssl.org> on Mon, 
> 12 Nov 2018 11:33:23 +0100 (CET), Richard Levitte  said:
> 
> > QUIC was mentioned a little more than a year ago.   Since then, it
> > seems that the drafts have moved forward with quite some speed:
> > 
> > https://tools.ietf.org/html/draft-ietf-quic-transport-16
> > https://tools.ietf.org/html/draft-ietf-quic-tls-16
> > https://tools.ietf.org/html/draft-ietf-quic-recovery-16
> > 
> > There seems to be an effort to have the next major HTTP version be
> > based on QUIC, at least if this blog is any indication:
> > 
> > https://daniel.haxx.se/blog/2018/11/11/http-3/
> > 
> > So the question is, should we start taking a closer look?  Last time,
> > it seems like the discussions were cautiously positive, but never
> > reached a conclusion.
> > 
> > Thoughts?  Anyone feeling enthusiastic and want to do something?
> > 
> > Cheers,
> > Richard
> > 
> > -- 
> > Richard Levitte levi...@openssl.org
> > OpenSSL Project http://www.openssl.org/~levitte/
> > 
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] QUIC, again

2018-11-12 Thread Richard Levitte
For those wanting to follow what's happening in QUIC space, this is a
good place to start: https://datatracker.ietf.org/wg/quic/about/

In message <20181112.113323.260349601387601601.levi...@openssl.org> on Mon, 12 
Nov 2018 11:33:23 +0100 (CET), Richard Levitte  said:

> QUIC was mentioned a little more than a year ago.   Since then, it
> seems that the drafts have moved forward with quite some speed:
> 
> https://tools.ietf.org/html/draft-ietf-quic-transport-16
> https://tools.ietf.org/html/draft-ietf-quic-tls-16
> https://tools.ietf.org/html/draft-ietf-quic-recovery-16
> 
> There seems to be an effort to have the next major HTTP version be
> based on QUIC, at least if this blog is any indication:
> 
> https://daniel.haxx.se/blog/2018/11/11/http-3/
> 
> So the question is, should we start taking a closer look?  Last time,
> it seems like the discussions were cautiously positive, but never
> reached a conclusion.
> 
> Thoughts?  Anyone feeling enthusiastic and want to do something?
> 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] QUIC, again

2018-11-12 Thread Richard Levitte
QUIC was mentioned a little more than a year ago.   Since then, it
seems that the drafts have moved forward with quite some speed:

https://tools.ietf.org/html/draft-ietf-quic-transport-16
https://tools.ietf.org/html/draft-ietf-quic-tls-16
https://tools.ietf.org/html/draft-ietf-quic-recovery-16

There seems to be an effort to have the next major HTTP version be
based on QUIC, at least if this blog is any indication:

https://daniel.haxx.se/blog/2018/11/11/http-3/

So the question is, should we start taking a closer look?  Last time,
it seems like the discussions were cautiously positive, but never
reached a conclusion.

Thoughts?  Anyone feeling enthusiastic and want to do something?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

--- Begin Message ---
Issue 4283 (https://github.com/openssl/openssl/issues/4283) has caused
me to take a close look at QUIC. This seems to have been getting a *lot*
of attention just recently. See the IDs below for details:

https://tools.ietf.org/html/draft-ietf-quic-transport-05
https://tools.ietf.org/html/draft-ietf-quic-tls-05
https://tools.ietf.org/html/draft-ietf-quic-recovery-05

For the uninitiated QUIC is a new general-purpose transport protocol
built on top of UDP. It provides applications with a secure stream
abstraction (like TLS over TCP) with reliable, in-order delivery, as
well as the ability to multiplex many streams over a single connection
(without head-of-line blocking).

It is *very* closely integrated with TLSv1.3. It uses the TLSv1.3
handshake for agreeing various QUIC parameters (via extensions) as well
as for agreeing keying material and providing an "early data"
capability. The actual packet protection is done by QUIC itself (so it
doesn't use TLS application data) using a QUIC ciphersuite that matches
the negotiated TLS ciphersuite. Effectively you can think of QUIC as a
modernised rival to TLS over TCP.

I've spent some time today reading through the IDs. It has become clear
to me that in order for OpenSSL to be used to implement QUIC there are a
number of new requirements/issues we would need to address:

- We need to provide the server half of the TLSv1.3 cookie mechanism. At
the moment an OpenSSL client will echo a TLSv1.3 cookie it receives back
to the server, but you cannot generate a cookie on the server side.

- We need to be able to support *stateless* operation for the
ClientHello->HelloRetryRequest exchange. This is very much in the same
vein as the stateless way that DTLSv1_listen() works now for DTLS in the
ClientHello->HelloVerifyRequest exchange. This is quite a significant
requirement.

- A QUIC server needs to be able to issue a NewSessionTicket on demand

- Ticket PSKs need to be able to have an embedded QUIC layer token (the
equivalent of the cookie - but embedded inside the PSK).

- We need to extend the "exporter" API to allow early_secret based
exports. At the moment you can only export based on the final 1-RTT key.

- TLS PSKs are transferable between TLS-TCP and QUIC/TLS-UDP. There are
some special rules around ALPN for this that may impact our current
logic in this area.

- Possibly a QUIC implementation will need to have knowledge of the
TLSv1.3 state machine because different TLSv1.3 handshake records need
to go into different types of QUIC packets (ClientHello needs to go into
"Client Initial" packet, HelloRetryRequest needs to go into a "Server
Stateless Retry" packet and everything else goes into "Client Cleartext"
or "Server Cleartext" packets). It may be possible for a QUIC
implementation to infer the required information without additional
APIs, but I'm not sure.

- QUIC places size limits on the allowed size of a ClientHello. Possibly
we may want some way of failing gracefully if we attempt to exceed that
(or maybe we just leave that to the QUIC implementation to detect).

I'm going to start working through this list of requirements, but if
anyone fancies picking some of it up then let me know. Also, did I miss
anything from the above list?

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

--- End Message ---
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project