Cryptography & Security Newsletter

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written 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.

Short News

• Researchers have discovered over 2,400 browser extensions that actively manipulate website security headers, one of them being HSTS.
• Hardenize started a new project to help with adoption of security standards. The first instalment, Hardenize Policy for Email Infrastructure, focuses on email security.
• Let’s Encrypt is on schedule to disable ACME v1 on June 1st, 2021. ACME v2 has been available for about three years now.
• A reminder that one of older Let’s Encrypt’s roots will expire in September 2021 and some older devices may start to experience certificate warnings.
• Microsoft Exchange administration interfaces were offline for a couple of days because of an expired certificate.
• Mozilla released a blog post cautioning about incorrect uses of their trust store.
• Separately, Mozilla also has started a conversation around quantifying the value of adding new CAs to the ecosystem.
• Rich Saltz is working on a new RFC that clarifies that certificate common names should not be used to verify server identities.
• nusenu released an analysis of malicious activity of Tor exit nodes. In May 2021, about 1,000 new anonymous nodes joined, making up 40% of the entire network.
• A new TrustAsia CT log for 2021 was accepted as qualified by Chrome. TrustAsia CT logs for 2022 and 2023 were accepted as qualified by Apple.

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.