November 22, 2016
Move aside TCP, Google has developed a new experimental protocol aimed at reducing web latency while providing security analogous to TLS. Features/benefits include:
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.
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:
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]
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).
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:
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.
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.
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.
Message data can include an additional PAD (padding) tag. This can be used to defeat traffic analysis since the padding keeps bandwidth usage constant.
In a study conducted at Purdue, the following results were found in regard to QUIC:
Here’s a brief summary of the attacks identified:
This is a very exciting time for the internet and a big step forward for HTTP/2!