QUIC working group looks to bring more security to Internet traffic

Pardue, from London, also works as a senior software engineer at Cloudflare, a U.S. web infrastructure and website security company. An edited version of the conversation appears below.

IETF blog: What is the QUIC working group? When did it start? 

Pardue: The QUIC Working Group (WG) is a collection of talented researchers, practitioners, engineers, developers, policy makers, infrastructure operators, service providers ... you name it. Since 2016, we've been working on standardizing version 1 of the QUIC protocol, including transport behavior, loss detection, recovery, congestion control, security, and, in unison with the HTTP Working Group, an application mapping of HTTP to QUIC. 

For those that might remember, the work on QUIC started long before 2016. We took that as a starting point and wrote a charter that would help us develop a set of documents that had the consensus of the working group and wider IETF community. And as we finish the work on version 1 with the publication of RFCs, we enter a new chapter for the working group. It focuses on maintenance and evolution of the protocol as well as becoming the home for new ideas that leverage the rich extensibility capabilities of QUIC. We have a bright future ahead. 

IETF blog: How does QUIC improve the performance, privacy and security characteristics of services that use it? 

Pardue: The QUIC transport protocol is secure by default, meaning it provides strong integrity, authenticity, and confidentiality for all that choose to use it. Services today that use TCP (with or without TLS) should treat QUIC as almost a drop-in replacement substitute. And with the Unreliable Datagram extension that the group is working on, we're on course to be a substitute for DTLS or other such protocols. The one key thing is that QUIC, unlike TCP, protects packet metadata – very little information is exposed to passive observers and no one in the middle is able to manipulate things like sequence numbers or options. This presents some challenges to conventional ways of managing traffic but it fixes a big problem – ossification. 

When a third party tinkers with your traffic without coordinating with you, they make assumptions about the protocol and the systems the protocol traverses. Those assumptions can create friction when the first party (the endpoints) want to improve or experiment with things. And where the friction is extreme it renders extensions moot or even breaks the protocol, leading to a reluctance or inability to change or evolve. Securing QUIC prevents un-coordinated tinkering and gives us an excellent platform to move ahead with. Today QUIC provides fast handshakes, thanks to Zero Round-Trip time, and many implementers have smart congestion controllers. Tomorrow, the base performance of the protocol can only get better. 

On the performance side of things, avoiding Head-of-Line blocking is the killer feature of QUIC. This is achieved via stream multiplexing which I'll talk about some more in a later question. This is less of a drop-in replacement than other parts of QUIC, and requires the application using QUIC to be smart about how it interacts with independent streams. 

IETF blog: How widely is QUIC deployed? How did it come to be widely deployed?

Pardue: As the QUIC working group has worked on developing the specifications we have seen many implementations of client and server code. Of those, a subset has made it into “production” deployments such as web browsers and public-facing services. Cloudflare made QUIC and HTTP/3 support publicly available to all in September 2019. We've been really happy to see people turning it on and testing with developer/canary/nightly channels of browsers such as Chrome, Firefox, and Safari. As the specifications near maturity, it’s very exciting to see client support start entering the stable channels and getting turned on by default. 

End users should start to benefit from QUIC's improved security and performance without having to take any manual action. According to data from Cloudflare Radar, in mid-January 2021 the global share of HTTP versions was approximately: 24 percent of HTTP/1.1, 75 percent for HTTP/2, and less than 1 percent for HTTP/3. By mid-February, adoption in HTTP/3 had grown to just over 5.5 percent, with HTTP/2 falling to 69 percent, and HTTP/3 growth substituting for HTTP/2 usage. By mid-May, HTTP/3 represented 12 percent of HTTP traffic share.

We expect the trend to continue as more browsers and websites get QUIC-enabled.

IETF blog: What’s the importance of stream multiplexing and encrypted transport protocol?

Pardue: I've explained how protection from tinkerers helps above in question 2, so won't repeat that here. But let’s not forget that private communications should be just that, private. Encrypted transports are a foundational building block to improving user security and privacy – they enable application developers a foundation on which to build additional security, such as the Web Origin model, same-origin policy, and restriction of web APIs to secure contexts. QUIC's stream multiplexing can help mitigate the phenomena of Head-of-Line (HoL) blocking, where a lost packet holds up everything behind it. This manifests in many ways that can affect end-user experiences. 

If some critical website script is blocked behind less urgent data, you can be stuck looking at a blank page. If part of your video stream is dropped, you can't simply skip to the bits you do have, instead you might end up watching a spinning icon while it buffers or manually reload and hope things resume where you left them. QUIC has ways to mitigate HoL blocking that if used correctly, can improve the quality of experience, especially helping in networks that experience regular problems. 

In TCP there is one logical bytestream; data sent in this stream is guaranteed to be received in-order. The TCP stream is split up into segments for transmission over the network using IP, and since the network is not guaranteed to be reliable, it might lose packets or reorder them. It's the job of TCP to handle such events and present the stream as expected. This usually works well but sometimes HoL blocking rears its ugly head. Imagine you sent the sequence A, B, C, D, E in separate packets and the third one was lost. The receiver gets the sequence A, B, D, E. It can't present all four values to the application, only the first contiguous range A, B.

QUIC streams can fix this. Each stream, identified by a 62-bit integer, is independent and behaves like its own mini-TCP, all under a common protection. A sender could choose to split A, B, C, D, E over different streams and the sender could read them out in any order. If a packet with one of the values gets lost, no problem, you just read everything as it arrives! The challenge however is reading the sequence back in the order it was sent. The stream ID can be used to help here but how that actually happens is described by an application mapping like HTTP/3. Solving HoL blocking is possible, but tuning it for the best quality of experience is the next area of opportunity. 

IETF blog: What’s next for QUIC?

Pardue: I'm super excited for the next chapter of QUIC. As people deploy version 1, we'll learn and identify potential improvements. QUIC versioning and extensibility is rich and robust. We have updated the working group charter in order to broaden the scope of work that we can consider. Some of the new ideas, like smarter retransmissions have been adopted, and we are considering candidates like qlog for richer standardized endpoint logging. Personally, I'm excited about the application-layer possibilities that QUIC is enabling. The IETF has already formed the MASQUE and WebTransport working groups that build upon QUIC foundations. The future is bright.