Network Performance

QUIC: Performance and Security at the Transport Layer

Date: November 1, 2016

In today’s Internet, latency is a crucial issue for online services and businesses. Changes of 100ms or less have significant, measurable impacts on user satisfaction and, therefore, revenue. This dynamic has been amplified recently by the move toward encrypting increasingly more Internet traffic with Transport Layer Security (TLS), an attempt to counter large-scale network surveillance. In addition to important security benefits, TLS adds several additional round trips to each connection, making latency an even more crucial issue. It should come as no surprise that efforts are being made to obtain the security of TLS with significantly reduced latency. One such effort is a new transport protocol called Quick UDP Internet Connections (QUIC).

Background

QUIC was developed by Google, implemented in Chrome in 2013, and today provides service for the majority of requests by Chrome to Google services. It operates as an application protocol over User Datagram Protocol (UDP) and integrates ideas from Transmission Control Protocol (TCP), TLS, and Datagram Transport Layer Security (DTLS) in order to provide both security comparable to TLS and minimal latency during connection setup. QUIC provides security by encrypting the application data and most of the protocol header. It provides improved latency with 0–RTT connection establishment, whereby a client that has previously communicated with a server can start a new connection without a three-way handshake, which enables it to send useful data in the very first round trip. The reduction in initial latency in comparison to TLS equals two or three round-trip times (RTTs), depending on whether TLS session resumption is enabled. QUIC improves upon TCP and TLS in a number of other ways, too, including introduction of multiple streams per connection to reduce head-of-line blocking and vastly improved acknowledgment information that eliminates retransmission ambiguity issues (Figure 1).

For these reasons, QUIC has attracted significant interest from the networking community. While some documentation about the protocol has been available since its initial release in Chrome and much of the code is available in the open source Chromium project, these sources often are incomplete and lag behind what Google has actually deployed. In response, Google has begun the process of standardizing QUIC through the IETF via a Bar BoF at IETF 93 and a BoF to charter a Working Group at IETF 96. The latest BoF filled the largest meeting room available and concluded with overwhelming consensus in favor of such a Working Group.

The central claims of QUIC—encryption and server authentication similar to TLS and significantly improved performance—are stated informally in the protocol documentation. Particularly for a security protocol, it is crucial to have a more formal analysis of the protocol in order to understand precisely what guarantees are being provided and what guarantees are not. To address this issue, Robert Lychev, Alexandra Boldryeva, Cristina Nita-Rotaru, and I developed a provable security analysis of QUIC that precisely characterized the security provided and then leveraged the results of that analysis to identify a number of performance attacks against QUIC. In 2015, we won the IRTF Applied Networking Research Prize for our work, titled “How Secure and Quick is QUIC? Provable Security and Performance Analyses”, which had been published that same year at the IEEE Symposium on Security and Privacy. We again presented our work at a well-attended Internet Research Task Force session at IETF 96.

Our Work

Our work presents a provable security analysis of QUIC that precisely characterizes its security guarantees. Such an analysis consists of a formal model of the protocol, a formal definition of security, and a proof by reduction that shows how QUIC satisfies the security definition. Unfortunately, existing formal security models from the analysis of TLS were unsuitable for QUIC, due to QUIC’s use of multiple session keys and the fact that QUIC must consider reordering and packet injection issues that TLS can hand off to TCP. As a result, we developed a new security model, which we called Quick Authenticated and Confidential Channel Establishment (QACCE). The new model considers attackers, who can initiate and observe communications between honest parties, as well as intercept, drop, reorder, or modify any exchanged messages. The attacker is assumed to have knowledge of all public keys and can adaptively learn and apply collected information. Selective compromise of servers and access to their secret keys and state is also possible. Given such an attacker, a secure protocol should allow parties to establish session keys and use them to send data with privacy and integrity.

We prove that QUIC can successfully protect against such a strong attacker and provide QACCE security, under reasonable assumptions about the encryption, authentication, and signing algorithms used. Interestingly, this security model provides different levels of security for data exchanged under QUIC’s initial and final session keys. These two keys are an optimization introduced to enable 0–RTT connections. Data sent in the first round-trip is encrypted with an initial key that is derived from a static Diffie Hellman value in a long-term server config object while data sent in all future messages is encrypted using a final session key derived from an ephemeral Diffie Hellman value sent in the first message from the server. This means that QUIC does not satisfy the traditional notion of forward secrecy provided by certain TLS modes, such as TLS-DHE. Forward secrecy is a property, which ensures that an adversary who compromises a server is unable to compromise prior connections to that server. In QUIC’s case, since the 0–RTT data is encrypted under the initial key derived from the server’s cached Diffie Hellman value, this data can be compromised if the server config object has not expired. However, since the final session key is derived from an ephemeral Diffie Hellman exchange, any data encrypted under it (i.e., data exchanged after the first RTT) is forward secret.

Using this analysis of the security guarantees provided by QUIC, we can consider possible attacks against QUIC’s performance and identify five performance-degradation attacks against it. It should be emphasized that these attacks do not impact the authenticity or confidentiality of data sent over QUIC; they impact only QUIC’s performance. But, performance, specifically latency, is a key motivating goal for the development and deployment of QUIC, and these attacks enable an attacker to deny clients access to services offered over QUIC by denial of service against the server or by disrupting a particular target connection. Interestingly, these attacks operate by leveraging the optimizations made to enable 0–RTT connections and either replaying cachable information about the server or manipulating unprotected packet fields.

The Server Config Replay Attack

Figure 2. Server config replay Attack

One attack that we identified is the server config replay attack. The server config is a signed object containing a variety of information about the server, including a Diffie Hellman value and the server’s supported encryption and signing algorithms. This object is designed to be cachable by a client for a specified lifetime and provides the client with all the information needed to perform a 0–RTT connection. It is retrieved from the server the first time a client connects. The server config replay attack takes advantage of the public, cachable nature of this object. In this attack, the attacker listens for new connection requests, and forges a message containing this server config and a randomly generated source address token (STK). This token is used to prevent IP spoofing and is treated by the client as an opaque string. This message races any response from the legitimate server; provided it wins, the client will retry the connection with this new server config and STK. However, the legitimate server has no record of this STK and so will reject the connection. Unfortunately, the client believes it has already received the first message from the server, and so will ignore this rejection message, causing the connection to linger in a stalled state for multiple seconds until the client’s connection establishment timer fires, abruptly terminating the connection. The other attacks we identified operate in a similar manner by either replaying cachable information or modifying unprotected packet fields (Figure 2).

Conclusion

By developing a provable security analysis of QUIC and investigating attacks against performance, we formalize the security that QUIC provides and identify areas of weakness in its current manner of optimizing performance. This work was well received at IETF 96, and we hope it will provide valuable insight as the recently chartered QUIC Working Group begins the standardization process. We look forward to seeing an even-better QUIC emerging from this process in the future.