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