FYI: Matt Caswell realized how critical TLSv1.3 (and subsequently OpenSSL) is to QUIC. -- -Todd Short // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet."
Begin forwarded message: From: Benjamin Kaduk via openssl-dev <openssl-...@openssl.org<mailto:openssl-...@openssl.org>> Subject: Re: [openssl-dev] QUIC Date: September 7, 2017 at 12:45:11 PM EDT To: openssl-...@openssl.org<mailto:openssl-...@openssl.org>, Matt Caswell <m...@openssl.org<mailto:m...@openssl.org>> Reply-To: Benjamin Kaduk <bka...@akamai.com<mailto:bka...@akamai.com>>, <openssl-...@openssl.org<mailto:openssl-...@openssl.org>> On 09/06/2017 05:24 PM, Matt Caswell wrote: Issue 4283 (https://github.com/openssl/openssl/issues/4283<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_4283&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=SApxT1dwQ12t7sTml0O3C5Zxwn9LVnjY7Hx3PBA0FXw&s=14jAp_dXwD_vSTsFa_yMlV7rrSTSokwEL83hzbv_zaU&e=>) 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dquic-2Dtransport-2D05&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=SApxT1dwQ12t7sTml0O3C5Zxwn9LVnjY7Hx3PBA0FXw&s=suQF_tIEpOj6XX2_1ZohhrztQbmQrPq8Em2Ob3hqo-I&e=> https://tools.ietf.org/html/draft-ietf-quic-tls-05<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dquic-2Dtls-2D05&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=SApxT1dwQ12t7sTml0O3C5Zxwn9LVnjY7Hx3PBA0FXw&s=TL4hpO1Bgmp8TV-aXazUdU8GZBCealRdZ1NCC8Zj_b4&e=> https://tools.ietf.org/html/draft-ietf-quic-recovery-05<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dquic-2Drecovery-2D05&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=SApxT1dwQ12t7sTml0O3C5Zxwn9LVnjY7Hx3PBA0FXw&s=06yufiB_0xv3D3louJQSpboJ_It8FjCgrEoNmWv5R_o&e=> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3802&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=SApxT1dwQ12t7sTml0O3C5Zxwn9LVnjY7Hx3PBA0FXw&s=Nf9Y6bpYT5qwRd4s9uW2dJcE7OTwfbK_bED98JBD4us&e=> 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
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
