[openssl-dev] QUIC

[Benjamin Kaduk]

On 09/06/2017 05:24 PM, Matt Caswell wrote:
> 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:

Yes, it's generated a lot of excitement and interest at the IETF.

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

The nature of the QUIC/TLSv1.3 integration is somewhat interesting. 
QUIC has its origins at Google, and the "Google QUIC" or gQUIC variant
is deployed on the public internet even now; since TLS 1.3 was not
available then, it uses a separate "quic-crypto" scheme for these
purposes.  quic-crypto, in turn, helped shape the evolution of TLS 1.3,
including the strong desire for 0-RTT functionality.

But, as I understand it, the intent is to leave enough hooks that a
different crypto layer could be used, including (but not limited to) a
subsequent version of TLS.

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

Yeah, the cookie is pretty clear to the UDP/"stateless" operation.

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

The expectation is that the state gets bundled into the cookie, yes.

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

I think https://github.com/openssl/openssl/pull/3802 is pretty close, in
this space.

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

It seems in keeping with our existing handling of early data, to at
least consider providing a separate API for these early exporter values.

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

We do have existing things like the message callback, but I won't try to
argue that that's an ideal situation for a QUIC implementor.  And the
QUIC layer could even parse out the unencrypted records for itself from
the output BIO, as silly as that would be.

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

(This is to limit the potential for a DoS amplification attack via
spoofed client address, since UDP does not provide the reachability
confirmation that TCP's handshake does, for the spectators.)

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

Nothing sticks out as missing to me, but I've not been following QUIC
development as closely as I'd like.

-Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170907/86e86aeb/attachment.html>