again capturing the intuition that such later compromise impede generic security of the composed protocol. Moreover, due to replays more than two sessions may derive the same session keys, a situation which contradicts the setting of two-party symmetric-key protocol security where keys are assumed to be shared between two parties only.
4.7
Further Work Extending the Model
We introduced the initial version of multi-stage key exchange model for the analyses of the QUIC protocol [FG14] and extended it along with the analysis of various TLS 1.3 drafts and handshake modes [DFGS15a, DFGS16, FG17] to the form presented here (cf. Chapters 5–7). Since then, and partially in parallel, the multi-stage key exchange model has been used and built upon by others in the following works.
Li et al. [LXZ+16] augment our multi-stage model by an additional notion of “levels” in order to analyze the cascading execution of multiple TLS 1.3 (resumption) handshakes as an alternative approach to the compositional security guarantees of our model (cf. Section 4.6).
Cohn-Gordon et al. [CGCD+17] build upon our multi-stage model to provide a formal analysis of the secure messaging protocol Signal [Sig]. They introduce a tweaked variant of the model to support a tree-like structure of stages instead of a linear sequence, in order to capture the complex key schedule and advanced security properties (like post-compromise security [CGCG16]) of the Signal protocol.
Brendel and Fischlin [BF17] adopt our multi-stage model in the smart card setting in order to analyze a 0-RTT extension of the Extended Access Control (EAC) protocol (see, e.g., [Int15]).
Cohn-Gordon et al. [CGCG+17] propose a design for a tree-based group key exchange protocol with strong security guarantees, in particular post-compromise security, to improve over current secure group messaging protocols. For their analysis, they define a group key exchange variant of our multi-stage model to capture their key updating mechanism.
Chapter
5
The QUIC Protocol
Summary. In this chapter we present our security analysis of the QUIC protocol proposed by Google in 2013 and globally deployed at Google in the meantime [QUI, LRW+17]. We first provide a cryptographic description of QUIC’s key exchange protocol. We then give our security analysis and results in the multi-stage key exchange model and discuss its implications and notes on the protocol design. The results in this chapter are based on a work published at ACM CCS 2014 [FG14].
5.1
Introduction
In 2013, Google announced the QUIC [QUI] (for “Quick UDP Internet Connections”) protocol, setting out to improve the efficiency of secure connections while maintaining security guarantees comparable to the de-facto standard TLS (Transport Layer Security) protocol. While, to this end, QUIC comprises substantial and complex engineering efforts to optimize efficiency, the focus in this chapter will be on the cryptographic connection establishment part of the protocol. QUIC employs a Diffie–Hellman-based key exchange protocol for establishing the keys for a secure connection, but particularly focuses on reducing the round complexity of the interactions. It starts with the client being able to deliver data to the server immediately—i.e., with zero round-trip time (0-RTT), protected under an intermediate cryptographic key. At some point, the server replies with its contribution to the key exchange. Both parties then switch to a stronger key and continue the interaction with that key. The basic version of the protocol is displayed in Figure 5.1.
As already outlined in Chapter 4, establishing multiple session keys (key1 and key2 in QUIC) demands a key exchange security model capturing interactions and dependencies between these keys. In QUIC, for example, we will see that the derivation of the final key key2 being protected under the intermediate key key1 makes the former’s secrecy dependent on the latter’s.
Analysis of QUIC. Google’s QUIC protocol will hence be the first protocol we study in our multi-stage key exchange security model from Chapter 4. It provides a reasonable starting point as it is simpler than the TLS protocol, whose multi-stage security in version 1.3 we will turn to in Chapters 6 and 7. Investigating QUIC also avoids the need to deal with the problem of key deployment for the finished message as in TLS versions up to 1.2 [DR08], which lead researchers to use alternative approaches for security analyses [JKSS12, KPW13, BFS+13]. We show that QUIC is a secure key exchange protocol, assuming idealized key derivation via random oracles, the Gap Diffie-Hellman assumption [OP01], and use of a secure channel. Here we distinguish between the keys of the two stages, showing that the stage-one key provides basic key secrecy, whereas the stage-two key yields forward secrecy.
Client C Server S
server’s static public key pkS server’s static secret key skS
generate ephemeral key pair eskC, epkC
compute key1 ← DH(eskC, pkS)
compute key1← DH(epkC, skS)
generate ephemeral key pair eskS, epkS
compute key2 ← DH(eskC, epkS) compute key2← DH(epkC, eskS)
epkC
{data}key1
{epkS}key1
{data}key2
Figure 5.1: High-level protocol run description of Google’s QUIC protocol with 0-RTT handshake.
DH(X, Y ) indicates the Diffie–Hellman secret computed from shares X and Y . {X}key indicates sending
X over a channel secured under key.
Note that our result about QUIC being a secure key exchange protocol shows that the protocol, as is, does not show any weakness, although the security bounds are far from being tight. Ideally, though, we would like to argue that QUIC, together with a secure channel protocol, provides a fully secure connection. This is where the compositional properties of our model and the composition result come into play. Recall from Section 4.6 that this result requires the key exchange protocol to be, in particular, (session-)key-independent and forward-secret. As the two keys derived in QUIC however are dependent, we first propose a slight modification of QUIC to turn it into a key-independent protocol, following ideas similar to those for TLS resumption. We then can conclude that compositional security with any symmetric-key protocol using the forward-secret second-stage session key is indeed achieved by the modified version of QUIC.
In summary, our results show that QUIC can be understood and analyzed as a multi-stage key exchange protocol. QUIC exhibits shows strong security properties, despite its comparatively low complexity. In particular, the trade-off between 0-RTT performance and forward secrecy is only one round trip. Still, as we discuss, with little effort QUIC can be strengthened further to facilitate a compositional analysis of its key exchange and channel component.