28 May 2021
Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Received monthly by more than 50,000 subscribers. Maintained by Hanno Böck.
Today we celebrate the release of QUIC, a brand-new reliable and secure protocol that marks a new direction in how networking standards are designed. Before QUIC, secure communication on the Internet involved several layers, most frequently TCP for reliable transport and TLS for security. This layered approach (via the OSI model) served us well, but there was a desire for even better performance, for which development of a specialised protocol was necessary.
That’s where QUIC comes in. The main use case covers a client that needs a large number of connections to the same server, in other words—browsers. QUIC avoids TCP and builds on UDP to provide a new protocol that’s always encrypted and provides better performance. The main wins for performance are faster connection setup, multiplexing, and better behaviour in face of packet loss. The main win for security is that QUIC is always encrypted and reuse of TLS 1.3. In the longer term, we should expect to see QUIC as the foundation for many new uses.
The main source of performance improvements is the reduced number of roundtrips that are required to setup a new connection. When you have a combination of TCP and TLS, each protocol performs its setup on its own, sequentially, and that requires two round trips (assuming TLS 1.3). QUIC can achieve the same in only one round trip, or even no round trips on resumption. The other main improvement comes from building on UDP, which potentially supports much better performance with slow connections with increased packet loss, for example mobile devices. With HTTP/2, for example, a loss of one packet means that all multiplexed connections stall. With QUIC, a loss of one packet affects only one stream, whereas the rest continue to operate as normal.
The performance promises of QUIC come with a caveat, which is that the servers must keep the initial handshake message small. Because QUIC builds on UDP, it must take care to resist amplification attacks, when someone sends a small packet from a fake source IP address and causes the server to send a proportionally large amount of data to the wrong place. Because of this, the initial QUIC packets (sent by clients) must be at least 1,200 bytes while servers are allowed to respond with up to 3,600 bytes (3x). Crucially, if there is more data to send, the server must wait for the client to acknowledge the connection, which introduces a latency of one round trip.
When done well, the server side of the handshake can be kept at around 3,000 bytes, but if the certificate chain or the OCSP stapled response are not optimal, they might tip the handshake over the maximum allowed size in QUIC. It’s the certificates that take up most of the space. There are currently efforts to reduce the required space with certificate compression, caching, or altogether new encoding mechanisms.
In the context of encryption, it’s particularly interesting to examine how QUIC uses TLS 1.3. If you recall, TLS itself is designed as two collaborative layers. The record layer, which provides transport protection, supports many multiplexed subprotocols. There are two main subprotocols, one that takes care of the handshake and negotiates encryption keys, and the other that holds application data.
QUIC assumes the role of the record layer: it encrypts the data directly but delegates all the complex cryptography to the TLS 1.3 handshake subprotocol. In effect, QUIC adopted TLS 1.3 as its sidekick. In this context, layering was an advantage, rather than a problem. You’ll find the details in RFC 9001. In the end, as far as encryption is concerned, QUIC behaves just like TLS 1.3 and it’s configured in the same way.
QUIC is a continuation of many years of work, that started with SPDY, led to HTTP/2, then QUIC, and (soon) HTTP/3. QUIC alone took about 5 years to standardise. Because it’s only been released today, you can’t exactly use it straight away; it will take some time for the implementations to mature and the support to spread widely. If you read this post and want to learn more, I recommend Daniel Stenberg’s excellent and concise HTTP/3 Explained. You can of course also delve into the QUIC RFCs.
This subscription is just for the newsletter; we won't send you anything else.
This month’s newsletter has been written by Ivan, who is standing in for Hanno. We wish Hanno a speedy recovery from his bicycle accident.
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 1,500 students who have benefited from more than a decade of deep TLS and PKI expertise.