Move aside TCP, Google has developed a new experimental protocol aimed at reducing web latency while providing security analogous to TLS. Features/benefits include:

• Zero roundtrip (0-RTT) connection time for returning connections.
• Congestion control: all packets carry new sequence numbers (easier to tell which packets are originals vs. retransmissions), allows for precise roundtrip-time calculation.
• Error correction: groups of packets contain a FEC packet which can be used to recreate a lost packet (no retransmission cost).
• Multiplexing without head-of-line blocking (in SPDY two different streams sharing the same TCP connection would both be affected by a lost TCP packet).
• Connection Migration: instead of (source address, source port, destination address, destination port) a 64bit connection id (CID) is used. This means you can change IP address or ports but still keep your connection alive–that means zero connection time even if your mobile phone switches from WiFi to Cellular!

QUIC was implemented in 2013 and is available in Chrome version >= 29 and Opera >= 16. For those of you interested in looking at the Chromium implementation of QUIC, look here. You can also find the Google Developers introduction to QUIC here.

Why QUIC?

The major goal of QUIC is to reduce latency on the internet today. Because of this, QUIC is implemented on top of UDP. Unlike TCP, UDP is more bare bones (it makes a best effort to deliver a packet across a network, but does not guarantee delivery…or in-order delivery). For things like gaming, video, and VOIP, this is usually ok (dropped video frames or momentary voice distortions are not catastrophic). Note that it would be impractical to choose a protocol other than UDP or TCP due to the existing internet infrastructure (servers, routers, operating systems, etc). Using a new protocol would require updates to the infrastructure and that would take a great deal of time to implement (think 5-15 years…IPv6 has been around since 1998 and is just starting to gain traction! ).

Some additional architectural features of QUIC:

• Servers can publish static configuration files for use by clients (with a longer lifespan so that it can be cached by clients). Subsequent connections to a server can retrieve configuration from the cache.
• Servers respond to initial connection requests with cert, hashes of the cert chain, and a synchronization cookie (includes things like the cookie-holder IP address and port at a particular date/time). Client proves identifity with synchronization cookie.
• Packet Pacing: packets are sent at regular intervals (this requires ongoing bandwidth estimation). More predictable traffic patterns means less likelihood of congestion and dropped packets meaning few retransmissions of missing data.
• Proactive Speculative Transmission: duplicate copies of the most important packets (incase they are lost during transmission). Ideal packet candidates for this are initial encryption packets and FEC packets.
• Cryptographic block boundaries are aligned with packet boundaries. This results in only needing to retransmit only the missing/corrupt packets, not the window of packets required to perform decryption.

Comparison of connection steps for TCP, TLS/TCP, and QUIC

Below you can see how QUIC stacks up against TCP and TLS/TCP in terms of # of roundtrips required. Remember, the time incurred by a roundtrip is governed by the speed of light and thus cannot be reduced any further. The best way to reduce connection time is to avoid unnecessary roundtrips! [source: chromium blog]

TCP: trips required to…

• Each connection: Establish TCP Connection
• Exchange Data

TLS over TCP: trips required to…

• Each connection: Establish TCP Connection
• New connections: Establish TLS Keys
• Resumed Connections: Resume Session (Session Identifiers introduced in SSL 2.0)
• Exchange Data

QUIC: trips required to…

• New Connections: Establish Connection + Negotiate key agreement
  • All subsequent data exchanged using final key
• Resumed Connections: Exchange data using previously negotiated key

As you can see above, one of the major drawbacks of TLS/SSL over TCP is that resuming disconnected sessions requires and extra handshake due to the protocol, not for security reasons. Furthermore, decryption of packets needs to be done in order due to TCP protocol (delayed packets can really slow down performance).

Security Considerations

What security considerations were taken into account with QUIC? Switching from TCP to UDP means that the application layer is now responsible for dealing with attacks. Here’s how QUIC addresses some common concerns:

IP Address Spoofing

To guard against IP spoofing, QUIC uses a source-address token. This is an encrypted byte string from server to client (client IP and server timestamp encrypted with AES-GCM). The server only sends this encrypted token to the client IP. Receipt of token is proof of ownership by the client IP. Clients can use this token in subsequent requests to demonstrate ownership of their IP. Old tokens or new IPs will trigger a refreshed token from the server. And if the cookie is stolen? The server only responds to the IP address in the token, so a different IP address would be ignored by the server. In the event that DHCP reassigns the IP address to a different client and the cookie is stolen…that is dealt with by keeping the token lifespan short enough to minimize the window of time that an IP address could be spoofed.

Replay Attacks

Unlike TLS, QUIC uses a unique nonce set by the client only (as compared to server and client nonces) to ensure that a request cannot be replayed at a later date (1 request processed per unique nonce). The server uses a shared register to store nonces. If a nonce exists in the register, the request will be rejected as it is seen as a replay. Keep in mind that the shared register is partioned across “orbits” (groups of servers which each maintain a set of nonces) for a limited period of time. This distributes nonces across the globe and prevents indefinite storage of nonces.

Handshake Costs

The configuration provided by a server provide the public keys required to encrypt communication. Unlike TLS/TCP, a single signing operation is not required for each connection, but a single signature suffices for many connections. Following the initial encrypted data, the server replies with an ephemeral (short amount of time) Diffie-Hellman value and the connection is rekeyed. This means that each connection is uniquely encrypted. This 2 step key derivation procedure is outlines in NIST SP 800-56C page 9.

Wire Protocol

Message data can include an additional PAD (padding) tag. This can be used to defeat traffic analysis since the padding keeps bandwidth usage constant.

So how secure is QUIC?

In a study conducted at Purdue, the following results were found in regard to QUIC:

• QUIC satisfied QACCE (an extension of Authenticated and Confidential Channel Establishment model which was used to prove TLS) under reasonable assumptions of the underlying building blocks. Attacking QUIC is not easier than attacking TCP and TLS.
• In the presence of sophisticated adversaries, QUIC may be unable to attain one of its major goals: zero roundtrip connection establishment.

Here’s a brief summary of the attacks identified:

• Server configuration replay attack: this requires an attacker to be approx 20ms closer to a client than the server. This results in abnormal connection termination and higher latency.
• Source address token replace attack: similar to a SYN Flood attack. Classic mitigation to Syn Flood attack is SYN-Cookies (single use, so cannot replay). QUIC’s 0-RTT goal means that server address tokens cannot be single use (albeit they can have shorter lifespans). As a result of this, there is a window of time that an attacker can replay spoofed packets.
• QUIC manipulation attacks: connection request can be rewritten to attempt to use an older less secure version of SSL (e.g. 2.0 – this has structural vulnerabilities). Even with SSL 3.0, these manipulations cause the attack to be caught, but at the end of the handshake resulting in a timeout and fallback to to TCP/TLS.
• Crypto Stream Offset Attack: similar to TCP ACK Storm attack. Results in inability to transfer any more data over the target data stream. This eventually results in a connection timeout.

This is a very exciting time for the internet and a big step forward for HTTP/2!