Networked Systems H (2021-2022)
Lecture 4: Improving Secure Connection Establishment
This lecture discusses some of the limitations of TLS v1.3, considering connection establishment performance, metadata leakage, and protocol ossification. It then introduces the QUIC transport protocol. QUIC is a new transport protocol, that tries to improve on the performance of TLS over TCP while providing additional features.
Part 1: Limitations of TLS v1.3
The first part of the lecture discusses some limitations of TLS v1.3. It explains why TLS slows down connection establishment and discusses the 0-RTT connection re-establishment feature, it's benefits, and its risks and limitations. It discusses metadata leakage from TLS connections, both data exposed in the TCP header and the Server Name Indication (SNI) field in the TLS handshake. And it reviews some of the protocol ossification issues that have affected TLS development.
00:00:00.433 In this lecture, I want to talk
00:00:03.300 about some ways in which secure connection
00:00:05.600 establishment is being improved in the Internet.
00:00:08.000 I’ll talk about some of the limitations
00:00:10.666 of TLS 1.3 that constrain its security,
00:00:13.100 and that slow down its connection establishment.
00:00:16.000 And I’ll talk about improvements being developed
00:00:18.000 to address these problems. Both to improve
00:00:21.800 TLS 1.3 when used with TCP,
00:00:23.700 and to entirely replace TCP and TLS
00:00:26.466 with a new transport protocol, QUIC,
00:00:28.800 that has faster connection establishment
00:00:31.233 and in-built security.
00:00:34.366 In the first part, I’ll talk about
00:00:36.766 some of the limitations of TLS 1.3
00:00:39.200 and how they’re being addressed.
00:00:41.500 I’ll revisit the problem of slow connection
00:00:43.966 establishment, and describe new issues around metadata
00:00:46.700 leakage and protocol ossification. And I’ll discuss
00:00:50.566 how TLS is being extended to solve these problems.
00:00:54.000 Then, in the following parts of the
00:00:56.800 lecture, I’ll talk about the QUIC transport protocol.
00:00:59.966 QUIC is a new transport protocol,
00:01:02.566 just finishing development in the IETF,
00:01:05.166 that aims to improve on the performance
00:01:08.166 and security of TLS and TCP,
00:01:10.733 and add some new features, while avoiding
00:01:13.766 problems due to protocol ossification.
00:01:17.000 To start with, though, I want to
00:01:19.566 talk about some of the limitations of
00:01:22.166 TLS 1.3.
00:01:24.000 The Transport Layer Security protocol, and TLS
00:01:27.466 1.3 in particular, has been a great success.
00:01:30.933 The protocol has been successfully extended and
00:01:33.900 updated over many years, to keep abreast
00:01:36.166 with security challenges.
00:01:38.233 It’s added new features to meet the
00:01:40.800 needs of new applications, such as datagram
00:01:43.066 TLS for security of video conferencing calls.
00:01:46.166 And it has good performance and is widely used.
00:01:50.100 TLS 1.3 is the most recent version
00:01:53.433 of TLS, and was standardised in 2018.
00:01:56.800 Compared to TLS 1.2, the previous version,
00:02:00.233 it provides some significant security
00:02:01.900 and performance improvements.
00:02:04.566 TLS 1.3 removed support for older and
00:02:07.966 less secure encryption and key exchange algorithms.
00:02:10.900 It removed support for algorithms that are
00:02:13.433 know to be secure if implemented correctly,
00:02:16.400 but that have proven difficult to implement
00:02:18.666 correctly. It improved performance of the handshake,
00:02:22.066 reducing the number of round-trips needed to
00:02:24.666 negotiate security.
00:02:26.100 And it simplified the design of the protocol.
00:02:29.900 Despite this, TLS 1.3 still has some
00:02:32.933 limitations that are difficult to fix.
00:02:36.400 Connection establishment is still relatively slow.
00:02:40.066 Connection establishment leaks
00:02:42.333 potentially sensitive metadata,
00:02:44.166 that can be viewed as a security risk.
00:02:46.833 And the protocol is ossified, due to
00:02:49.766 poor quality implementation and middleboxes,
00:02:52.400 and difficult to extend.
00:02:56.666 The first issue is TLS connection establishment performance.
00:03:01.400 TLS is a security protocol, not a
00:03:05.033 transport protocol, and needs to be run
00:03:07.766 inside an existing transport-layer connection.
00:03:10.200 In practise, this means that TLS usually
00:03:12.966 runs inside a TCP connection.
00:03:15.966 When connecting to a TLS-enabled server,
00:03:18.766 a client must first establish a TCP
00:03:21.400 connection to the server. This proceeds with
00:03:24.300 the usual TCP connection establishment handshake.
00:03:26.800 The client sends a TCP segment with
00:03:29.700 the SYN bit set, indicating the start of the connection.
00:03:33.966 The server responds with a SYN ACK.
00:03:36.700 And the client completes
00:03:38.400 the handshake with an ACK packet.
00:03:41.000 This handshake takes one-and-a-half round trips to
00:03:43.566 complete, with the client being able to
00:03:46.100 send data after the first round trip.
00:03:48.600 That is, the client can send a
00:03:50.600 data packet immediately after it sends the
00:03:52.433 final ACK packet in the handshake,
00:03:54.400 without waiting for a response from the server.
00:03:58.100 When using TLS, this initial TCP data
00:04:01.300 packet contains a TLS ClientHello message.
00:04:05.366 This is the first part of the
00:04:06.800 TLS handshake. It indicates the version of
00:04:09.966 TLS the client supports, and starts the
00:04:12.833 negotiation of the encryption and authentication keys.
00:04:17.000 The TLS server responds with a TLS
00:04:20.266 ServerHello message containing the information needed to
00:04:23.500 establish the secure connection. Then the client
00:04:26.166 responds with a TLS Finished message,
00:04:28.500 confirming the secure connection.
00:04:31.500 It’s only at this point,
00:04:32.866 two full round trip times after starting
00:04:34.900 the connection establishment,
00:04:36.466 that the client can send a
00:04:37.900 secure request to the server, along with
00:04:39.966 the TLS Finished message.
00:04:42.500 And the earliest that a response can
00:04:44.866 be received is one round trip later,
00:04:47.266 a total of three round trips after
00:04:49.633 starting the connection setup.
00:04:53.600 Do these three round trips matter?
00:04:57.000 The table on the right shows some
00:05:00.266 typical round trip times from Glasgow.
00:05:02.733 Three round trips can easily be somewhere
00:05:04.900 in the 250 to 500 millisecond range.
00:05:08.600 Measurements show that an average web page
00:05:10.900 fetches about 1.7 megabytes of data,
00:05:13.633 comprising around 69 HTTP requests, and using
00:05:17.866 around 15 TCP connections.
00:05:21.000 And about 80% of those connections use TLS.
00:05:25.166 Some of the TCP and TLS connections
00:05:27.633 run in parallel, certainly, but not all of them.
00:05:31.066 And most of the time taken to
00:05:33.366 load a typical web page is actually
00:05:35.100 spent waiting for TCP and TLS
00:05:37.133 connection establishment handshakes.
00:05:40.000 If we want to make web pages
00:05:41.666 load faster, reducing the connection establishment time
00:05:45.033 is a very effective way of doing so.
00:05:49.566 Can we speed up the TLS connection establishment handshake?
00:05:54.800 There are two ways.
00:05:57.000 The first is a technique known as
00:05:59.433 0-RTT connection re-establishment.
00:06:02.833 This lets us save the security parameters
00:06:05.466 the first time we connect to a
00:06:07.200 server, and re-use them in future.
00:06:09.800 It improves performance if we fetch more
00:06:12.466 than one page from the same website.
00:06:15.000 I’ll talk about 0-RTT connection re-establishment in
00:06:17.933 a minute.
00:06:20.500 The second way to improve the connection
00:06:22.266 establishment time, is if we can somehow
00:06:25.033 overlap the TCP and TLS handshakes
00:06:27.466 so they happen in parallel.
00:06:30.166 At present, we open a TCP connection,
00:06:32.933 which takes one round trip before the
00:06:35.666 client can send data, and then negotiate
00:06:38.600 the TLS security parameters, taking another round
00:06:41.266 trip. We could speed up the process
00:06:44.333 by overlapping these two handshakes.
00:06:47.000 For example, we could send the TLS
00:06:49.733 ClientHello message along with the TCP SYN
00:06:52.433 packet, and the TLS ServerHello message could
00:06:55.766 be sent in the SYN-ACK packet.
00:06:58.466 This would let the whole connection establishment
00:07:01.500 handshake, TCP and TLS, complete in one go.
00:07:04.900 Now, doing this with TCP would require
00:07:07.833 widespread operating system changes, and updates to
00:07:10.666 all the firewalls in the world,
00:07:13.066 and so it isn’t likely to happen.
00:07:16.000 But the QUIC transport protocol, that I’ll
00:07:18.566 talk about in later parts of the lecture,
00:07:20.566 does support this optimisation.
00:07:26.000 The 0-RTT connection re-establishment technique builds on
00:07:29.300 the observation that it’s common to connect
00:07:32.566 to a previously known TLS server.
00:07:35.500 We frequently fetch more than one web
00:07:38.266 page from a site. Or visit the
00:07:40.400 same sites every day. Or connect to
00:07:42.333 the same messaging, chat, or video conferencing server.
00:07:46.766 Surely it should be possible to shortcut
00:07:48.933 the connection establishment in such cases,
00:07:51.433 and reuse information we exchanged the first
00:07:53.533 time to speed things up?
00:07:56.000 It is, but to do so we
00:07:58.866 need to understand three things.
00:08:01.000 Firstly, what the role of the TLS
00:08:03.466 handshake, and how are the security parameters
00:08:07.933 Second, how can we encrypt initial data
00:08:10.533 on re-establishing a secure connection?
00:08:13.566 And, finally, what are the potential risks
00:08:16.400 in short-cutting the key exchange?
00:08:20.433 So, what is the role of the TLS handshake?
00:08:24.900 It does two things.
00:08:27.000 The first is to use public key
00:08:30.066 cryptography to securely establish a session key.
00:08:33.133 That session key is then used to
00:08:34.900 encrypt the data being sent over the
00:08:36.466 TLS connection, using a symmetric encryption algorithm.
00:08:40.900 The ClientHello and ServerHello messages, exchanged in
00:08:44.900 the TLS handshake, are used to derive
00:08:47.500 this session key.
00:08:49.900 In TLS 1.3, this is done using
00:08:52.733 the ephemeral elliptic curve Diffie-Hellman key exchange
00:08:56.400 algorithm – ECDHE.
00:09:00.000 The TLS client and server exchange their
00:09:02.800 public keys in the ClientHello and ServerHello
00:09:05.600 messages, along with a randomly chosen value.
00:09:08.766 The public keys and random values exchanged
00:09:11.200 in the TLS handshake, and the private
00:09:14.000 keys known only to each of the
00:09:16.800 endpoint, are used to derive the session
00:09:19.600 key, using the elliptic curve Diffie-Hellman algorithm.
00:09:22.500 The maths of how this is done
00:09:24.800 is complicated, and I’m not going to try to explain it.
00:09:27.966 The key point, though, is that every
00:09:30.033 TLS connection, even if between the same
00:09:32.666 client and server, generates a unique session key.
00:09:36.400 This provides a property known as forward
00:09:39.100 secrecy. If the encryption key for one
00:09:42.066 TLS connection somehow leaks to the public,
00:09:45.100 then it exposes the data sent over
00:09:47.366 that connection, but it doesn’t help an
00:09:49.800 attacker break the encryption on any other
00:09:52.400 connections between those endpoints.
00:09:56.000 The other role of the TLS handshake
00:09:58.333 is to retrieve the server’s certificate,
00:10:00.333 that will have a digital signature from
00:10:02.666 some Certificate Authority, part of the public
00:10:05.000 key infrastructure, allowing the client to confirm
00:10:07.333 the identity of the server.
00:10:12.000 The ECDHE algorithm requires information from both
00:10:15.100 the ClientHello and the ServerHello messages to
00:10:18.166 derive a session key. It can’t be
00:10:21.266 used until the handshake has completed.
00:10:24.000 This is why TLS usually takes a
00:10:26.866 complete round trip to negotiate the session keys.
00:10:29.866 You can’t start encrypting the data until
00:10:32.633 after the ClientHello and ServerHello messages have
00:10:34.933 been exchanged, since those messages are used
00:10:37.700 to derive the encryption key.
00:10:40.766 0-RTT Connection Reestablishment gets around this by
00:10:44.100 sharing a key in one TLS session,
00:10:47.000 to be used in the next.
00:10:50.000 The first time a particular client makes
00:10:51.966 a connection to a TLS server,
00:10:54.333 the server sends it two additional bits
00:10:56.533 of information along with its ServerHello message.
00:11:00.000 It sends a PreSharedKey and a SessionTicket.
00:11:04.000 The PreSharedKey is an encryption key,
00:11:06.233 that the client can use to encrypt
00:11:08.200 data it sends to the server.
00:11:10.633 And the SessionTicket tells the server which
00:11:12.833 key was given to the client.
00:11:15.633 These are sent over the encrypted TLS
00:11:17.633 connection, so they’re only known to the
00:11:19.733 client and the server.
00:11:22.500 When it later reconnects to the same
00:11:24.700 server, the client can use this information
00:11:27.500 to send encrypted data along with the
00:11:29.633 ClientHello message.
00:11:32.000 In this case, the client establishes a
00:11:34.833 TCP connection to the server. Then,
00:11:37.233 it sends a TLS ClientHello message to
00:11:40.033 the server in the usual way.
00:11:42.466 But, along with this, it also sends
00:11:45.266 the SessionTicket it was previously given, and some data.
00:11:49.000 This data is encrypted using the PreSharedKey
00:11:51.400 that was sent by the server in
00:11:53.333 a previous connection,
00:11:54.433 and goes along with the SessionTicket.
00:11:58.000 On receiving such a message, the server
00:12:00.733 responds with a ServerHello as normal.
00:12:03.066 It also uses the SessionTicket to lookup
00:12:05.833 its copy of the PreSharedKey, and decrypt
00:12:08.233 the data sent from the client.
00:12:11.000 If the server wants to reply to
00:12:13.566 the client, it sends its response along
00:12:16.100 with the ServerHello message. Since the server
00:12:18.666 has received the ClientHello message, and knows
00:12:21.233 what it sent in its ServerHello message,
00:12:23.800 it can derive an ephemeral session key
00:12:26.333 and use it to encrypt the response.
00:12:29.000 Similarly, the client can decrypt that response,
00:12:31.833 since it will follow ServerHello that provides
00:12:34.666 the information needed to complete the key exchange.
00:12:38.100 This handshake is shown on the right of the slide.
00:12:43.066 This process of sending a PreSharedKey in
00:12:45.566 one TLS session, and using it to
00:12:48.066 encrypt the data sent in the initial
00:12:49.900 message of the following session, is known
00:12:52.166 as 0-RTT connection re-establishment.
00:12:55.933 It provides a way for the client
00:12:57.833 to send encrypted data to the server
00:12:59.400 in the first packet it sends after
00:13:01.000 the TLS connection is opened. That is,
00:13:04.200 it allows data to be sent with
00:13:05.733 no additional round trips.
00:13:08.500 The usual TLS handshake also takes place,
00:13:11.333 with the ClientHello and ServerHello messages used
00:13:14.366 to derive a session key.
00:13:16.333 The PreSharedKey is only used to encrypt
00:13:18.500 the very first message sent from the client to the server
00:13:21.166 on the connection.
00:13:25.600 0-RTT connection re-establishment allows data to be
00:13:29.133 sent immediately,
00:13:30.466 reducing TLS connection establishment latency.
00:13:35.700 It introduces two risks.
00:13:38.866 The first is that data sent along
00:13:41.800 with the ClientHello, and encrypted using a
00:13:44.633 PreSharedKey, is not forward secret. The use
00:13:47.433 of a PreSharedKey links two TLS connections together.
00:13:52.533 The key sent is securely over one connection,
00:13:55.633 encrypted using the ephemeral session key of that session,
00:13:59.000 and is used to encrypt the data sent in the
00:14:00.933 first message of the next connection.
00:14:04.000 If, for some reason, the ephemeral session
00:14:06.666 key for the first session is exposed,
00:14:09.333 breaking the encryption of that session,
00:14:11.633 then it can be used to extract
00:14:14.266 the PreSharedKey. This, in turn, breaks the
00:14:16.700 encryption for the data sent in the
00:14:18.833 first message of the next session.
00:14:22.000 The rest of the data sent in
00:14:23.866 the next session is safe, because it’s
00:14:26.133 encrypted using the ephemeral session key for
00:14:28.100 the next session, not the PreSharedKey.
00:14:32.000 Secondly, data sent along with the ClientHello
00:14:35.266 message and encrypted using a PreSharedKey is
00:14:37.800 subject to a reply attack.
00:14:41.000 If an on-path attacker captures and re-sends
00:14:43.666 the TCP segment containing the ClientHello,
00:14:45.966 the SessionTicket, and the data protected with
00:14:48.666 the PreSharedKey, that data will be accepted
00:14:51.333 by the server again, and the server
00:14:54.033 will respond, trying to complete the handshake.
00:14:56.700 This will fail, since the connection has
00:14:59.400 already been established, but by then the
00:15:02.066 data has already been accepted and processed by the server.
00:15:06.000 The TLS record protocol, used once the
00:15:08.633 connection has been established, can protect against
00:15:11.266 such replay attacks, but to do so
00:15:13.900 it uses the information exchanged in the handshake.
00:15:17.666 TLS isn’t able to protect against replay
00:15:20.400 of 0-RTT data sent in the first
00:15:22.633 message from the client to the server.
00:15:25.500 Accordingly, if you use TLS with 0-RTT re-establishment,
00:15:30.700 you should make sure that any
00:15:32.133 data you send in the first message
00:15:33.700 is idempotent. That is, it won’t do
00:15:36.633 any harm if it’s received twice.
00:15:41.000 Because of these two limitations, it’s important
00:15:43.800 to be careful when using 0-RTT data in TLS.
00:15:47.600 The 0-RTT connection re-establishment mode
00:15:50.300 can improve performance, but has to be
00:15:53.266 used with care to avoid replay attacks.
00:16:00.000 The use of 0-RTT connection re-establishment can
00:16:03.466 improve connection setup times, if used carefully.
00:16:07.000 There are a couple of other limitations
00:16:09.566 of TLS that you should be aware of, though.
00:16:12.933 The first is that TLS runs over
00:16:14.733 a TCP/IP connection, and the TCP and
00:16:18.233 IP headers are not encrypted.
00:16:21.666 This exposes certain information to anyone eavesdropping
00:16:24.433 on the connection.
00:16:27.000 An eavesdropper can observe the IP addresses
00:16:29.500 between which the packets are sent,
00:16:31.166 and the TCP port numbers.
00:16:34.000 The TCP port numbers tell you what
00:16:36.833 service is being used. For example,
00:16:39.233 they expose whether the TLS connection is
00:16:42.066 made to a web server, an email
00:16:44.033 server, a video conferencing server, a messaging
00:16:46.533 server, or whatever.
00:16:49.000 And the IP addresses often tell you
00:16:51.133 what site is being accessed.
00:16:54.000 Small sites tend to use shared hosting,
00:16:56.733 where many websites run on a shared
00:16:59.466 server with a single IP address,
00:17:01.800 but popular sites need dedicated machines to
00:17:04.533 host them, and so have their own
00:17:06.966 IP addresses. An eavesdropper can often use
00:17:10.000 the IP addresses to identify what site
00:17:11.733 is being accessed.
00:17:14.000 Maybe that doesn’t matter.
00:17:16.600 Knowing that a particular user has connected
00:17:18.666 to an IP address owned by Google
00:17:20.333 maybe doesn’t tell you much.
00:17:22.500 But knowing that they connected to an
00:17:24.400 IP address that hosts a website giving
00:17:26.766 information about a particular disease, or for
00:17:29.833 a particular political party, or for a
00:17:32.633 particular niche social network, might expose more
00:17:35.866 information about the user, even without knowing
00:17:38.766 what they said or being able to
00:17:40.366 access the data sent over that connection.
00:17:45.000 The TCP header also sends sequence numbers unencrypted.
00:17:48.966 This exposes how much information was
00:17:51.400 sent over the connection, and how fast
00:17:53.933 the data is being downloaded.
00:17:57.000 This information is often less sensitive than
00:17:59.233 the IP addresses and TCP port numbers,
00:18:01.700 but not always.
00:18:04.000 For example, it’s been shown to be
00:18:06.100 possible to identify what movie someone is
00:18:08.266 watching, on a site like Netflix,
00:18:09.933 just by looking at the pattern of
00:18:11.600 download rates for each scene, even if
00:18:13.866 the data is encrypted. The TCP sequence
00:18:17.333 numbers expose this information.
00:18:22.000 A bigger risk with TLS is that,
00:18:24.366 when used with HTTPS, the TLS ClientHello
00:18:28.700 message will include the Server Name Indication extension.
00:18:33.100 The server name indication provides the name
00:18:35.466 of the site being requested, so the
00:18:37.900 server knows what public key to include
00:18:40.366 in its ServerHello message.
00:18:42.966 It’s needed to support shared hosting,
00:18:45.366 where many websites are hosted on a
00:18:47.200 single web server with a single IP
00:18:48.900 address, where the server can’t tell what
00:18:51.333 site is being requested based on the
00:18:53.800 address to which the client connects.
00:18:56.000 Since the client can’t know how many
00:18:58.133 sites are hosted on each server,
00:18:59.733 it has to always send the server
00:19:01.700 name information field to indicate what server it wants.
00:19:05.000 And worse, the server name indication field
00:19:08.000 has to be unencrypted. This is because
00:19:11.000 it’s sent in the first packet,
00:19:12.500 before the session key has been negotiated,
00:19:15.000 because it’s used to determine what server
00:19:17.800 generates the ServerHello.
00:19:20.833 Similarly, the server name indication can’t be
00:19:23.200 protected by a PreSharedKey, since that’s provided
00:19:26.533 by the server, and the goal is
00:19:28.733 to select the server.
00:19:31.000 The server name information is a privacy risk
00:19:34.500 It exposes the name of the
00:19:36.200 server to which you’re connecting
00:19:37.766 to anyone eavesdropping on the path.
00:19:41.500 Is it a significant risk?
00:19:43.433 Well, that’s not clear.
00:19:46.166 As we saw on the previous slide, the IP address
00:19:49.466 of the site is always exposed,
00:19:51.300 and that’s often enough to identify the
00:19:53.266 site you’re accessing, whether or not the
00:19:55.133 site name is exposed.
00:19:57.666 Fundamentally, TLS runs over the Internet.
00:20:00.733 And the Internet always exposes the IP
00:20:03.466 addresses in the packets, making it possible
00:20:06.166 to tell who is accessing what site.
00:20:09.000 If you care about this problem,
00:20:11.000 you need to use an application like
00:20:12.633 The Onion Router, Tor, to protect your
00:20:18.933 The final issue I want to highlight
00:20:21.200 with TLS, is that of protocol ossification.
00:20:25.066 TLS is very widely implemented, but there
00:20:28.600 are many poor quality implementations.
00:20:31.000 As an example, the TLS ClientHello indicates
00:20:33.733 the version of TLS used by the
00:20:36.433 client. The server is supposed to look
00:20:38.933 at this, and look at the different
00:20:40.866 versions of TLS that it supports,
00:20:43.200 and send a ServerHello in response indicating
00:20:45.766 the most recent compatible version.
00:20:49.000 If the ClientHello indicates support for TLS
00:20:51.666 1.3, for example, but the server only
00:20:54.933 supports TLS 1.2, the server is supposed
00:20:58.300 to respond with a ServerHello saying it
00:21:01.100 supports TLS 1.2. The client will then
00:21:04.133 decide if this is sufficient, and if
00:21:05.833 it wants to communicate.
00:21:09.000 During the development of TLS 1.3,
00:21:11.133 though, it was noticed that some TLS
00:21:13.633 servers would crash if the ClientHello message
00:21:16.300 used a version number different to TLS 1.2.
00:21:20.600 Similarly, some firewalls were found that inspected
00:21:24.766 TLS ClientHello messages, and blocked the connection
00:21:28.733 if a version other than TLS 1.2 was used.
00:21:33.000 When early versions of TLS 1.3 were
00:21:36.166 deployed, using version number 1.3 in their
00:21:39.200 ClientHello messages,
00:21:40.433 measurements showed that these problems
00:21:42.600 affected around 8% of TLS servers,
00:21:45.266 and prevented TLS 1.3 from working in
00:21:48.100 those cases.
00:21:50.000 That is, around 8% of sites were
00:21:52.600 running buggy implementations of TLS, or had
00:21:55.200 buggy firewalls, that didn’t correctly implement TLS
00:21:57.800 version negotiation, and so would fail if
00:22:00.400 a newer version of TLS was used.
00:22:06.000 The designers of TLS decided that having
00:22:08.866 8% of connections fail when using TLS
00:22:11.766 1.3 was too much.
00:22:13.500 So they changed the design.
00:22:17.000 TLS 1.3 now pretends to be TLS
00:22:20.200 1.2 in the version number in its
00:22:23.366 ClientHello and ServerHello messages. But, it also
00:22:26.566 sends an extra extension header in those
00:22:29.766 messages, to say “Actually, I’m really TLS 1.3”.
00:22:33.033 Experience and testing showed that older TLS
00:22:36.300 servers, that only support TLS 1.2,
00:22:38.700 are more likely to ignore this extra
00:22:41.500 extension header, than they are to correctly
00:22:44.133 respond to a change in the version number field.
00:22:47.766 That is, when a TLS 1.3 client
00:22:50.566 talks to TLS 1.2 server, the TLS
00:22:54.466 1.2 server is likely to ignore the
00:22:56.433 extension header and see only the version
00:22:59.300 number in the ClientHello. It will respond
00:23:03.100 to this, and negotiate TLS 1.2.
00:23:07.000 But, when a TLS 1.3 client talks
00:23:10.033 to a TLS 1.3 server, the TLS
00:23:13.033 1.3 server will see the extension,
00:23:15.633 and know it should ignore the version
00:23:18.633 number field that says TLS 1.2,
00:23:21.233 and instead go with the version signalled
00:23:24.233 in the header. It will then respond
00:23:27.266 with a ServerHello, which also says TLS
00:23:30.266 1.2 in the version field, but that
00:23:33.300 has an extension header included to indicate
00:23:36.300 that it’s really using TLS 1.3.
00:23:39.000 This is horrible.
00:23:41.000 It’s a kludge written into the TLS
00:23:43.400 standard, because experience showed that there were
00:23:46.666 too many broken implementations of TLS out there.
00:23:49.866 The built-in version negotiation feature of TLS
00:23:52.966 turned out to be unusable in practice.
00:23:56.000 There were millions of deployed TLS servers
00:23:59.033 where trying to negotiate a TLS version
00:24:02.066 different to TLS 1.2 would cause the server to crash.
00:24:06.500 Upgrading them all was infeasible.
00:24:09.066 The only workaround was to change the
00:24:12.533 way the protocol negotiated what version to
00:24:15.966 use, while leaving the older version there
00:24:19.433 for backwards compatibility.
00:24:21.000 Protocol ossification is a significant concern.
00:24:25.000 And the problem does not only occur
00:24:28.966 with TLS.
00:24:30.100 Widely deployed faulty implementations constrain the design
00:24:34.200 of most protocols.
00:24:36.000 One of the biggest challenges in networked
00:24:38.666 systems is being able to change the protocol
00:24:40.733 without breaking previously deployed implementations.
00:24:43.933 Even if those implementations are buggy and
00:24:46.266 broken in different ways.
00:24:51.000 How do we avoid protocol ossification?
00:24:55.233 Well, ossification occurs when extension mechanisms in
00:24:58.900 the protocol are not used. When the
00:25:02.700 protocol allows flexibility in principle, but the
00:25:05.866 implementations of the protocol don’t use that flexibility.
00:25:09.866 For example, TLS 1.3 was released ten
00:25:13.700 years after TLS 1.2.
00:25:17.500 There was a period of ten years
00:25:20.500 when TLS was is use, and getting
00:25:23.466 increasingly popular, where only TLS 1.2 was used.
00:25:26.966 This allowed people to build implementations of
00:25:29.833 TLS that didn’t do version negotiation correctly,
00:25:32.633 because they didn’t need to. There were
00:25:35.466 no new versions to negotiate, so no-one
00:25:38.300 properly tested that feature.
00:25:40.000 The same happened with other features of TLS.
00:25:44.000 And the same happens with other protocols.
00:25:48.000 This hints at the solution to ossification.
00:25:51.000 Protocols ossify if they have features or
00:25:54.266 extension mechanisms that aren’t used. The implementations
00:25:57.533 of those features, those extension mechanisms,
00:26:00.300 aren’t properly tested, so buggy code gets
00:26:03.566 deployed, and constrains future changes.
00:26:06.000 So, why not use those features? Why
00:26:08.766 not use those extension mechanisms?
00:26:12.000 The idea is called GREASE. Generate Random
00:26:15.566 Extensions and Sustain Extensibility.
00:26:19.500 If the protocol allows extensions, send extensions.
00:26:22.400 Send meaningless dummy extensions that get ignored
00:26:25.300 if you have nothing else to send,
00:26:27.766 but make sure your protocol uses its
00:26:29.833 extension mechanisms.
00:26:32.000 If the protocol allows different versions,
00:26:34.500 negotiate different versions. Change the version number
00:26:37.400 occasionally, just to prove you can.
00:26:40.000 Do this even if you don’t need to.
00:26:43.433 That is “use it or lose it”.
00:26:46.566 Assume that any features of your system
00:26:49.233 that aren’t regularly used won’t get properly
00:26:51.766 tested, and won’t be usable in practice,
00:26:54.333 so make sure that all the features
00:26:56.900 get regularly used.
00:27:01.000 This concludes our discussion of TLS 1.3.
00:27:03.933 We’ve focussed on the limitations of TLS
00:27:06.966 in this part but, to be clear,
00:27:09.900 TLS 1.3 is a highly effective and
00:27:12.833 highly secure protocol. It’s a significant improvement
00:27:15.800 on prior versions of TLS. It’s faster
00:27:18.733 and it’s more secure.
00:27:20.500 But, TLS runs within a TCP connection
00:27:23.433 and must wait for that TCP connection
00:27:26.400 to be established, and this slows down
00:27:29.333 the handshake. And, because it runs in
00:27:32.266 TCP, some metadata is leaked that can
00:27:35.233 potentially expose sensitive information.
00:27:37.000 In the next parts, I’ll talk about
00:27:39.833 QUIC, a new transport and security protocol
00:27:42.666 that aims to address these limitations of TLS.
Part 2: QUIC Transport Protocol: Development and Basic Features
The second part of the lecture introduces the QUIC transport protocol. QUIC is a new transport protocol, designed to replace and improve on the combination of TCP and TLS. It reviews the history and development of QUIC, and outlines the features and benefits it provides. A high-level outline of the operation of a QUIC connection is provided.
00:00:00.200 In this second part,
00:00:01.433 I want to move on from talking about the limitations
00:00:03.600 of TLS and TCP,
00:00:05.133 and talk instead about the QUIC Transport Protocol.
00:00:08.400 QUIC is an attempt to replace and approve on TCP.
00:00:12.000 It incorporates TLS and various other extensions.
00:00:16.833 In this part, I'll talk about the development of QUIC
00:00:19.400 and its basic features.
00:00:21.166 Then, in the following parts,
00:00:23.133 I'll explain how QUIC establishes connections,
00:00:25.733 transfers data, and avoids ossification.
00:00:31.233 As we saw in the previous part of this lecture,
00:00:33.733 there are three main limitations of TLS 1.3
00:00:36.766 when running over TCP.
00:00:39.500 First, it's slow to establish a secure connection,
00:00:42.666 because the TCP connection establishment handshake,
00:00:45.900 and the TLS security perimeter negotiation,
00:00:48.866 proceed in series, one after the other.
00:00:52.600 Secondly TLS leaks some metadata about the connection.
00:00:57.100 And finally, both TLS and TCP are ossified,
00:01:00.333 and have become difficult to extend.
00:01:03.566 QUIC tries to solve these problems.
00:01:06.666 It's a single protocol
00:01:08.133 that provides both the transport and security features.
00:01:11.400 It reduces connection establishment latency,
00:01:14.433 by overlapping the connection setup
00:01:16.200 and encryption key negotiation.
00:01:18.833 It tries to avoid metadata leakage
00:01:21.100 through the use of pervasive encryption.
00:01:23.800 And it tries to prevent ossification
00:01:25.933 by systematic application of GREASE
00:01:28.300 and through encryption of more of the transport headers.
00:01:34.666 QUIC is a new protocol.
00:01:37.600 Development started in 2012
00:01:39.833 as a project inside Google
00:01:41.800 to improve the security and performance of the web.
00:01:45.466 One of the outcomes of that project was SPDY,
00:01:48.233 which was adopted by the IETF
00:01:50.100 and eventually became HTTP/2.
00:01:52.366 The other was QUIC.
00:01:55.400 Google transferred control of the QUIC protocol to the IETF
00:01:58.866 in 2016, and the IETF formed a working group
00:02:02.233 to standardize and develop the protocol.
00:02:05.733 The IETF then spent five years
00:02:07.800 updating and improving the protocol,
00:02:09.866 publishing 34 drafts,
00:02:11.933 and going through a couple of thousand pull requests
00:02:14.033 and issues of the specification on GitHub.
00:02:17.800 The final RFCs,
00:02:19.266 RFC 8999 through to 9002,
00:02:22.933 describing the protocol,
00:02:24.866 were eventually published in May 2021.
00:02:29.400 The final result
00:02:30.900 is clearly inspired by Google's initial proposal,
00:02:34.800 but it's also been significantly changed
00:02:37.033 as a result of the IETF process.
00:02:39.200 ]And it's now a much better protocol.
00:02:41.533 The result is more extensible,
00:02:43.700 has a better security solution
00:02:45.766 that's more compatible with TLS
00:02:47.700 and the security solutions used in the web,
00:02:50.800 and it provides a cleaner basis for further development.
00:02:56.666 So what is QUIC?
00:02:58.866 Well, the figure on the slide shows how QUIC
00:03:01.400 relates to the other layers of the Internet protocols.
00:03:05.400 As we see, QUIC performs most of the functions of TCP,
00:03:09.500 completely subsumes TLS,
00:03:11.700 and adds some features from HTTP.
00:03:15.533 Essentially, is trying to replace TCP and TLS,
00:03:19.033 and add a more useful API on top of them.
00:03:23.133 QUIC runs on top of UDP.
00:03:27.266 That is, QUIC packets are sent as the
00:03:29.433 payload within UDP packets,
00:03:31.500 rather than running directly on IP.
00:03:34.966 This was done for ease of deployment and development.
00:03:39.466 On top of that, QUIC provides reliability,
00:03:42.600 ordering, and congestion control.
00:03:45.100 These are the features usually provided by TCP.
00:03:50.166 It also incorporates TLS security,
00:03:52.766 and provides the same security guarantees as TLS 1.3.
00:03:58.733 And, finally, QUIC adds the idea of
00:04:00.966 stream multiplexing from HTTP/2.
00:04:03.666 That is, where a TCP connection
00:04:06.400 delivers a single stream of data,
00:04:08.566 QUIC allows multiple different streams of
00:04:10.800 data to be sent over a single connection.
00:04:14.466 The result is a general purpose,
00:04:16.733 reliable, congestion controlled,
00:04:19.100 and secure, client-server transport protocol.
00:04:24.400 QUIC is intended to be useful for any application
00:04:27.366 that currently uses TCP,
00:04:29.233 and it aims to provide a better, more secure,
00:04:32.066 replacement for TCP.
00:04:35.366 It was also designed to run HTTP effectively
00:04:38.433 and improves web applications.
00:04:41.866 In parallel with the development of QUIC,
00:04:44.000 the IETF is also developing an HTTP/3,
00:04:47.433 which is the version of the HTTP that runs on top of QUIC,
00:04:50.733 and is optimized to use the features of QUIC.
00:04:56.566 One of the key benefits of QUIC
00:04:58.733 is that it overlaps the connection establishment
00:05:01.000 and security handshakes.
00:05:04.366 On the left, we see the process by which a TLS connection
00:05:07.633 is established running over TCP.
00:05:11.566 As we saw in the previous part of the lecture,
00:05:13.666 it proceeds in two stages.
00:05:17.066 First, the TCP connection is established,
00:05:19.866 with a SYN, SYN-ACK, ACK exchange.
00:05:24.266 Then, TLS takes over
00:05:27.466 to negotiate the security parameters and encryption keys,
00:05:30.600 and to authenticate the server.
00:05:33.100 It exchanges, the TLS ClientHello,
00:05:35.700 ServerHello, and Finished messages.
00:05:39.400 And only then can the data be sent;
00:05:41.500 as HTTP request and response in this example.
00:05:46.533 QUIC, as we see on the right,
00:05:48.900 combines the first two stages into one.
00:05:52.166 And, as we'll see in the next part of this lecture,
00:05:54.866 QUIC sends the equivalent of the TCP SYN
00:05:58.033 and TLS ClientHello messages in one packet
00:06:01.600 at the start of the connection.
00:06:04.466 This begins connection setup,
00:06:06.300 and starts to negotiate the security parameters,
00:06:08.866 in one message.
00:06:11.866 The response contains the equivalent of the TCP SYN-ACK,
00:06:15.200 and the TLS ServerHello,
00:06:17.000 combined into one message.
00:06:19.966 This establishes the connection
00:06:21.733 and provides the security parameters.
00:06:24.900 Then, the final packet in the handshake
00:06:27.300 sends the equivalent of the TCP ACK
00:06:29.400 and TLS Finished messages,
00:06:31.433 and the initial data,
00:06:32.866 again all wrapped up into one message.
00:06:35.800 The result is that QUIC saves one round trip
00:06:38.566 compared to the combination of TCP and TLS.
00:06:42.033 Its normal case establishes a secure connection
00:06:44.966 as fast as TCP and TLS
00:06:47.466 can perform 0-RTT session resumption,
00:06:50.166 and without the limitations of session resumption.
00:06:54.366 And QUIC also supports the 0-RTT session resumption mode.
00:06:58.933 This allows the very first packet sent from a client
00:07:01.566 to a previously known server,
00:07:03.333 to both establish the connection,
00:07:05.400 negotiate security parameters,
00:07:07.633 and carry an initial request.
00:07:10.966 This let's QUIC achieve the best possible performance,
00:07:13.966 to send a request to a server
00:07:15.800 and get the response one round-trip time later.
00:07:22.366 QUIC allows applications to send
00:07:24.433 and receive streams of data.
00:07:27.766 Unlike TCP, where each TCP connection
00:07:30.933 allows a single stream of data to be sent,
00:07:33.300 and a single stream of data to be received,
00:07:35.933 QUIC allows for more than one stream of
00:07:38.100 data to be sent, and received on each connection.
00:07:42.166 This lets application separate out different objects,
00:07:45.266 delivering each on separate
00:07:47.033 stream within the QUIC connection.
00:07:49.666 For example,
00:07:50.566 when fetching a web page that includes multiple images,
00:07:53.666 QUIC would allow each image to be sent on a separate
00:07:56.500 stream within that connection,
00:07:58.533 rather than requiring a new connection to be open for each.
00:08:03.800 The data for these connections
00:08:05.500 is sent within QUIC packets,
00:08:07.600 and QUIC packets are, in turn,
00:08:09.500 sent within UDP data grams.
00:08:12.566 Each QUIC packet starts with a header
00:08:14.833 and contains one or more frames of data.
00:08:17.966 The frames contain data for the individual streams,
00:08:20.733 acknowledgments, and other control messages.
00:08:27.400 QUIC packets can be long header packets
00:08:29.733 or short header packets.
00:08:32.266 At the start of a connection,
00:08:34.000 QUIC sends what are known as long header packets.
00:08:36.933 The format of these is shown on the slide.
00:08:41.566 Long header packets start with a common header.
00:08:45.566 This common header begins with a single byte
00:08:48.000 where the first two bits are set to one
00:08:50.366 o indicate that it's a long header packet.
00:08:53.833 The next two bits of this byte,
00:08:55.800 labelled TT in the diagram,
00:08:58.133 indicate the type of the long header packet,
00:09:00.733 and the remaining four bits of this bytes are unused.
00:09:06.733 This byte is followed by a version number,
00:09:09.266 the destination connection identifier,
00:09:11.966 source connection identifier,
00:09:14.066 and the packet-type specific data.
00:09:18.466 The connection identifiers allow a QUIC connection
00:09:21.533 to survive address changes.
00:09:24.500 For example,
00:09:25.433 if a smartphone connected to a home Wi-Fi network
00:09:28.300 establishes a connection to a server,
00:09:30.700 and then moves out of range of the Wi-Fi
00:09:33.033 and switches to its 4G connection,
00:09:35.133 then its IP address will change.
00:09:38.633 This change an IP address
00:09:40.166 would cause a TCP connection to fail.
00:09:43.900 The connection identifies allow a QUIC connection, though,
00:09:47.666 to automatically reconnect to the server
00:09:50.133 and continue where it left off.
00:09:54.333 Following the connection identifiers
00:09:56.300 is packet type-specific data.
00:09:59.433 There are four different types of long header
00:10:01.833 packet in QUIC.
00:10:04.700 An initial packet is used to initiate a connection
00:10:07.733 and start the TLS handshake.
00:10:09.800 It plays the same role as a TCL SYN packet
00:10:13.433 and a TLS ClientHello.
00:10:16.966 A 0-RTT packet is used to carry the idempotent data
00:10:21.266 sent when the 0-RTT session resumption is being used.
00:10:26.433 A handshake packet is used to complete the TLS handshake.
00:10:31.300 Depending on its contents,
00:10:33.000 a handshake packet is either the equivalent of a
00:10:37.566 TCP SYN-ACK, with a ServerHello,
00:10:40.533 or a TCP ACK with a TLS Finished message.
00:10:45.166 And the Retry packet is used to force address validation,
00:10:48.266 as part of connection migration,
00:10:50.433 and to prevent some types of denial of service attack.
00:10:56.000 These different types of QUIC long header packet
00:10:58.500 all contained QUIC frames,
00:11:00.333 are all sent inside UDP datagrams.
00:11:03.700 And,to improve efficiency,
00:11:05.866 QUIC allows several Initial, 0-RTT,
00:11:09.300 and handshake packets to be included
00:11:11.166 in a single UDP datagram,
00:11:13.133 one after the other,
00:11:14.766 followed by short header packet.
00:11:20.700 QUIC switches to sending short header packets
00:11:23.366 once the connection has been established.
00:11:26.866 QUIC short header packets omit the version number
00:11:29.433 and source connection identifier to save space,
00:11:32.233 since these can be inferred to be the same
00:11:34.433 as those sent during the connection establishment handshake.
00:11:37.833 And there's currently only one type of short header packet,
00:11:40.733 known as 1-RTT packets.
00:11:43.533 And these are used for all of the packets
00:11:45.400 sent after the QUIC handshake is completed,
00:11:47.933 and contain a sequence of encrypted and
00:11:49.800 authenticated QUIC frames.
00:11:55.733 Both long and short header packets contain QUIC frames.
00:12:00.600 Frames provide the core functionality of QUIC.
00:12:05.100 And there are many different types of frame.
00:12:08.866 CRYPTO frames are used to carry TLS messages,
00:12:11.866 such as the ClientHello, ServerHello, and Finished messages
00:12:15.500 used during the connection establishment handshake
00:12:18.300 to negotiate encryption keys.
00:12:21.266 STREAM and ACK frames
00:12:23.766 send data and acknowledgments on a stream.
00:12:27.800 Migration between the interfaces
00:12:29.933 is supported by the PATH_CHALLENGE and PATH_RESPONSE frames.
00:12:34.033 And the other types of frame control the
00:12:35.800 progress of a QUIC connection.
00:12:39.966 In many cases, QUIC frames
00:12:42.166 play the role taken taken in TCP by header fields.
00:12:46.933 For example, a TCP header
00:12:51.200 contains an acknowledgement field
00:12:52.966 that indicates the next packet expected.
00:12:55.966 The QUIC header does not.
00:12:58.600 Rather, QUIC packets include an ACK frame
00:13:01.500 that carries that information.
00:13:04.600 This makes QUIC more flexible and more extensible.
00:13:08.566 Rather than having a fixed header
00:13:10.333 that becomes difficult to change,
00:13:12.366 QUIC can just add new frame types
00:13:14.433 if it wants to send different types of control information.
00:13:21.133 That concludes our discussion of the history of QUIC
00:13:23.566 and it's basic features.
00:13:26.166 In the next part,
00:13:27.333 I'll talk in more detail about how connection
00:13:29.466 establishment works in QUIC,
00:13:31.433 and how QUIC reliably transfers streams of data.
Part 3: QUIC Transport Protocol: Connection Establishment and Data Transfer
The third part of the lecture discusses QUIC connection establishment and data transfer in more detail. It explains the QUIC connection establishment handshake, and shows how it overlaps the TLS security parameter negotiation and connection establishment operations into one handshake, to speed up connection establishment compared to TLS over TCP. And it outlines the process by which QUIC connections transfer data over streams, showing how the multi-streaming nature of QUIC improves on TCP.
00:00:00.366 In this part, I want to follow
00:00:02.233 on from the introduction to QUIC,
00:00:03.766 and talk in detail about how QUIC
00:00:05.666 establishes connections and transfers data.
00:00:10.000 Like TCP, a QUIC connection proceeds in
00:00:13.266 two phases. It starts with a handshake,
00:00:15.500 and then moves on to a data
00:00:17.766 transfer phase.
00:00:20.266 The QUIC handshake uses long header packets.
00:00:23.366 It establishes the connection, negotiates encryption keys,
00:00:26.866 and authenticates the server
00:00:29.166 The data transfer phase uses short header
00:00:31.900 packets. It’s where the data is sent
00:00:34.533 and received, and where acknowledgements are generated,
00:00:37.600 after the connection has been established.
00:00:42.000 QUIC improves on the performance of TCP
00:00:44.966 and TLS by combining the connection establishment
00:00:47.966 handshake and the TLS handshake into one
00:00:52.466 A QUIC connection starts with the client
00:00:55.200 sending a UDP datagram containing a QUIC
00:00:58.166 Initial packet to the server. This Initial
00:01:01.133 packet plays the equivalent role to a
00:01:04.133 TCP SYN packet and indicates that the
00:01:06.033 client wishes to establish a connection.
00:01:08.900 The Initial packet also contains a QUIC
00:01:11.666 CRYPTO frame. Inside that CRYPTO frame is
00:01:15.233 a TLS ClientHello message, the same as
00:01:17.933 if TLS was being used over TCP.
00:01:22.233 That ClientHello message starts the negotiation of
00:01:25.166 the encryption keys and other security parameters.
00:01:28.566 The QUIC Initial packet therefore simultaneously starts
00:01:32.300 both the connection establishment and the TLS handshake.
00:01:37.300 In response to this, the server sends
00:01:39.733 a QUIC Initial packet and a QUIC
00:01:41.566 Handshake packet back to the client.
00:01:44.400 These are both included in a single UDP datagram.
00:01:49.000 The Initial packet sent from the server
00:01:51.733 back to the client plays the role
00:01:54.466 of the TCP SYN-ACK packet, and indicates
00:01:57.200 to the client that the server is
00:01:59.966 willing to establish the connection. The Initial
00:02:02.700 packet also includes a CRYPTO frame containing
00:02:05.433 a TLS ServerHello message, that provides the
00:02:08.166 information needed to finish negotiating encryption keys.
00:02:11.000 Along with the Initial packet is a
00:02:14.100 QUIC Handshake packet. This contains the information
00:02:17.200 needed for TLS to authenticate the server,
00:02:20.300 and to negotiate any QUIC extensions used.
00:02:23.233 Once this initial packet and the handshake
00:02:26.100 packet arrives at the client, the connection
00:02:28.733 is ready to go. Both the client
00:02:31.333 and server have agreed to communicate,
00:02:33.566 and they both have the information needed
00:02:35.466 to encrypt and authenticate
00:02:36.633 the data sent over the connection.
00:02:40.000 The client concludes the handshake, and starts
00:02:42.933 the data transfer, by sending a third
00:02:45.866 packet. This is a UDP datagram that
00:02:48.766 contains a QUIC Initial Packet, a QUIC
00:02:51.700 Handshake Packet, and a 1-RTT short header
00:02:54.633 packet. This second QUIC Initial packet contains
00:02:57.566 an ACK frame, acknowledging the Initial packet
00:03:00.900 sent by the server.
00:03:02.833 The QUIC Handshake packet contains a CRYPTO
00:03:05.700 frame, that in turn contains the TLS
00:03:08.100 Finished message needed to complete the security handshake.
00:03:12.033 And the QUIC 1-RTT packet contains a
00:03:14.833 STREAM frame, with the initial data sent
00:03:16.900 from the client to the server.
00:03:21.000 The format of a QUIC Initial packet
00:03:23.133 is shown on the slide. It’s a
00:03:25.400 long header packet, used during the QUIC
00:03:27.800 connection establishment handshake.
00:03:30.800 QUIC Initial packets play two roles.
00:03:35.000 Firstly, they’re used to synchronise the client
00:03:38.000 and server state. In this respect,
00:03:40.333 they play the same role as TCP’s
00:03:42.533 SYN and SYN-ACK packets.
00:03:45.266 They also carry a CRYPTO frame,
00:03:47.400 containing either a TLS ClientHello or a
00:03:49.966 TLS Finished message, as part of the
00:03:52.666 encryption setup.
00:03:54.633 And they can also contain ACK frames.
00:03:58.000 The Initial packets combine connection setup and
00:04:02.033 security negotiation into one packet.
00:04:05.000 QUIC Initial packets can also carry an
00:04:07.266 optional Token.
00:04:08.966 A QUIC server can refuse a connection
00:04:11.900 attempt, and send a Retry packet to
00:04:13.900 the client containing a Token. If this
00:04:17.200 happens, the client must retry the connection,
00:04:19.666 providing the Token in its Initial packet.
00:04:22.666 If the Token matches, the connection establishment
00:04:25.866 then proceeds as normal.
00:04:28.166 This is used to prevent connection spoofing.
00:04:30.800 And to validate that a connection that’s
00:04:32.533 being re-established after an IP address change
00:04:35.533 is valid.
00:04:39.500 QUIC Handshake packets complete the TLS 1.3
00:04:42.700 exchange. They contain either a TLS ServerHello
00:04:45.866 message or a TLS Finished message,
00:04:48.600 contained within a CRYPTO frame.
00:04:51.433 The combination of the TLS ClientHello,
00:04:54.533 sent in the Initial packet, and the
00:04:56.966 TLS ServerHello and Finished messages, sent in
00:05:00.066 the Handshake packets, completes the TLS security
00:05:03.266 handshake. It works just the same as
00:05:05.966 TLS over TCP, except that the messages
00:05:08.500 are sent inside QUIC packets.
00:05:11.900 Handshake packets use a long header,
00:05:13.933 and have the format shown on the
00:05:15.466 left of the slide.
00:05:17.433 In most cases, a Handshake packet is
00:05:20.100 sent in the same UDP datagram as
00:05:22.300 an Initial packet, to reduce overheads.
00:05:25.233 If the combined packet is too big
00:05:27.800 to fit in a single UDP datagram,
00:05:29.900 though, the Initial and Handshake packets may
00:05:32.133 be sent in two separate datagrams.
00:05:36.000 The normal QUIC connection establishment takes one
00:05:38.900 round trip, after which both client and
00:05:41.900 server have agreed to communicate and have
00:05:44.433 the information they need to derive the
00:05:46.033 symmetric encryption key.
00:05:49.000 If this is too slow, QUIC also
00:05:51.533 supports TLS 0-RTT session re-establishment.
00:05:55.900 This works in a similar way to
00:05:57.866 TLS over TCP. The QUIC client and
00:06:01.100 server establish a connection as normal,
00:06:03.866 and the server sends a PreSharedKey and
00:06:06.300 a SessionTicket to the client.
00:06:09.500 When the client next establishes a QUIC
00:06:12.300 connection to that server, it adds the
00:06:15.100 SessionTicket to the CRYPTO frame it sends
00:06:17.066 in its initial packet, along with the
00:06:19.466 TLS ClientHello message.
00:06:22.000 And it also includes a QUIC 0-RTT
00:06:25.266 packet, containing a STREAM frame that carries
00:06:28.566 data encrypted using the PreSharedKey.
00:06:31.000 The QUIC server can use the SessionTicket
00:06:33.766 to look up its copy of the
00:06:35.633 PreSharedKey, and uses that to decrypt the
00:06:38.366 stream data sent in the 0-RTT packet.
00:06:42.566 The server then responds with QUIC Initial
00:06:45.166 and Handshake packets, as normal, along with
00:06:48.133 a 1-RTT short header packet containing a reply.
00:06:52.200 As with TLS over TCP, the data
00:06:55.800 sent in the 0-RTT packet is not
00:06:58.033 forward secret, and needs to be idempotent
00:07:00.800 since it’s potentially subject to replay attacks.
00:07:04.500 The difference is that 0-RTT session re-establishment
00:07:08.200 in QUIC really does send the data
00:07:11.333 in the very first packet, after zero
00:07:14.400 RTTs, whereas TLS over TCP sends it
00:07:16.733 in the first packet after the TCP handshake.
00:07:22.000 The result of all this is that
00:07:24.000 QUIC establishes a secure connection, in the
00:07:26.666 usual case, in one round trip,
00:07:29.566 whereas TLS over TCP needs two round trips.
00:07:33.400 QUIC combines connection establishment and encryption key
00:07:36.300 negotiation into a single handshake.
00:07:38.966 TLS-over-TCP runs
00:07:41.066 the two handshakes sequentially.
00:07:43.200 QUIC therefore speeds up the connection establishment.
00:07:49.000 Once the handshake has finished, QUIC switches
00:07:51.900 to sending short header packets. These short
00:07:54.800 header packets are used to transfer,
00:07:56.900 and acknowledge, data.
00:07:58.833 Each short header contains a Packet Number
00:08:01.533 field. This plays a similar role to
00:08:04.400 the sequence number in TCP segments.
00:08:07.000 Unlike TCP, though, QUIC Packet Numbers increase
00:08:10.000 by one for each packet sent.
00:08:12.733 Packet numbers in QUIC count the number
00:08:15.600 of packets sent. In contrast, the TCP
00:08:18.600 sequence number counts the number of bytes
00:08:21.000 of data sent.
00:08:23.000 The QUIC header does not include any
00:08:26.000 equivalent of the TCP acknowledgement number.
00:08:28.233 Instead, ACK frames are sent as part
00:08:31.033 of the protected payload data, to indicate
00:08:33.100 received packet numbers.
00:08:36.000 Also in contrast to TCP,
00:08:38.200 QUIC never retransmits packets.
00:08:41.166 If the UDP datagram containing
00:08:43.266 a QUIC packet is lost, QUIC will
00:08:46.100 retransmit the frames of data that were
00:08:48.366 in that packet in new QUIC packets,
00:08:51.233 and those packets will have new sequence numbers.
00:08:54.733 TCP, on the other hand, retransmits lost
00:08:58.000 packets with their original sequence number.
00:09:00.733 This means TCP cannot tell the difference
00:09:03.700 between the arrival of a retransmitted packet,
00:09:06.233 and a very delayed arrival of the
00:09:08.133 original packet. QUIC can always tell these
00:09:11.333 apart, since they have different packet numbers.
00:09:14.466 This simplifies the design of QUIC’s congestion
00:09:17.033 control algorithm, compared to TCP.
00:09:21.000 We’ll talk more about congestion control in Lecture 6.
00:09:25.100 Finally, a QUIC short header packet ends
00:09:28.900 with a protected payload section. This contains
00:09:32.766 encrypted and authenticated QUIC frames. These can
00:09:36.300 be STREAM frames containing data, ACK frames
00:09:39.866 containing acknowledgements, or other control data.
00:09:44.000 QUIC sends acknowledgements for received packets in
00:09:47.066 ACK frames. The slide shows the format
00:09:49.666 of an ACK frame.
00:09:52.000 ACK frames are sent inside long- and
00:09:55.100 short-header packets. Unlike TCP, the acknowledgements are
00:09:58.166 not part of the QUIC packet headers.
00:10:01.266 Also unlike TCP, acknowledgements indicate the sequence
00:10:04.433 numbers of QUIC packets that were received.
00:10:07.533 TCP sequence numbers and acknowledgements count the
00:10:10.600 number of bytes sent, whereas QUIC counts
00:10:13.000 the number of packets sent.
00:10:17.000 Finally, data is sent within STREAM frames,
00:10:19.866 that are sent within QUIC packets,
00:10:22.300 that are contained within UDP datagrams.
00:10:24.800 The format of a STREAM frame is
00:10:27.366 shown on the right.
00:10:29.333 It contains a stream identifier, the offset
00:10:32.100 of the data within the stream,
00:10:33.866 the length of the data, and the
00:10:35.866 data itself.
00:10:38.366 QUIC provides multiple reliable byte streams within
00:10:41.366 a single connection.
00:10:43.533 Data for each stream is delivered reliably
00:10:46.766 and, in the order it was sent,
00:10:49.200 within that stream, but data order is
00:10:52.533 not preserved between streams.
00:10:55.500 For example, assume that a client has
00:10:58.166 a connection to a server and is
00:11:00.100 sending data on two streams, stream A
00:11:02.033 and stream B, within that connection.
00:11:04.933 The client first sends a message on
00:11:07.033 stream A, and then it sends another
00:11:09.200 message on stream B.
00:11:11.900 All the data sent on stream A
00:11:14.200 will arrive reliably and in the order
00:11:16.033 it was sent. The same is true
00:11:18.533 of stream B. But the message sent
00:11:21.133 on stream A, which was sent first,
00:11:23.966 might arrive after the message sent on
00:11:26.366 stream B.
00:11:28.533 That is, QUIC avoids head-of-line blocking between
00:11:31.366 streams, but not within a stream.
00:11:34.366 We’ll talk more about head of line
00:11:36.033 blocking in Lecture 5.
00:11:39.000 There are two ways to view QUIC streams.
00:11:42.933 You can view QUIC streams as allowing
00:11:45.066 you to send multiple unframed byte streams
00:11:47.833 sent within a single connection. In this
00:11:51.500 view, a QUIC connection offers the same
00:11:53.633 service model as several parallel TCP connections.
00:11:58.266 Alternatively, you can view each QUIC stream
00:12:01.233 as framing a message. In this view,
00:12:04.600 a QUIC connection delivers a series of
00:12:06.833 framed messages, each sent on a separate stream.
00:12:11.033 They’re both entirely reasonable ways of looking
00:12:13.733 at a QUIC connection, but they lead
00:12:16.366 people to use QUIC in different ways.
00:12:20.000 QUIC is quite flexible, and is different
00:12:22.500 to TCP. It’s also new. We’re still
00:12:26.966 developing best practices for how to use
00:12:29.166 it, how to view the multiple connections.
00:12:35.000 This concludes our discussion of QUIC connection
00:12:38.633 establishment and data transfer.
00:12:41.366 In the next part, I’ll talk about
00:12:43.233 how QUIC tries to avoid protocol ossification.
Part 4: QUIC Transport Protocol: Avoiding Ossification
The final part of this lecture explains why QUIC is designed to run over UDP, rather than running natively on IP. It discusses the protocol ossification and deployment concerns that drove this choice, and the tools that QUIC employs to help prevent further ossification: protocol invariants, pervasive encryption of transport headers, and GREASE. It concludes by reviewing the benefits and costs of switching to QUIC.
00:00:00.633 In the final part of the lecture,
00:00:02.900 I’d like to discuss some features of
00:00:04.900 QUIC that are intended to avoid ossification.
00:00:07.766 And I’d like to touch a little
00:00:09.566 on the costs and benefits of using QUIC.
00:00:13.533 One of the unusual features of QUIC
00:00:15.600 is that it’s a transport protocol that
00:00:17.533 runs over another transport protocol. QUIC runs
00:00:20.866 over UDP, rather than running directly on IP.
00:00:24.600 Why is this?
00:00:26.666 Well, there are two reasons.
00:00:29.300 The first is to make end-system deployment
00:00:31.900 in user-space applications easier.
00:00:35.000 It’s difficult to implement protocols that run
00:00:37.566 directly over IP.
00:00:39.800 The native API that the existing transport
00:00:42.066 protocols, TCP and UDP, use to talk
00:00:45.533 to the IP implementation is hidden inside
00:00:48.800 the operating system kernel. It’s an internal
00:00:51.700 interface, that’s generally undocumented,
00:00:54.466 proprietary, and inaccessible.
00:00:56.866 Anything built at this level needs to
00:00:59.200 run within the operating system kernel,
00:01:01.100 and will be very tightly tied to
00:01:03.166 the details of that kernel.
00:01:05.000 There’s also a reasonably portable interface,
00:01:07.500 known as raw sockets, that lets you
00:01:10.433 send packets directly over IP. The raw
00:01:13.366 sockets interface is not the easiest API
00:01:15.700 to use, tends to be relatively low
00:01:17.766 performance, and offers limited control, but it
00:01:20.933 could be workable.
00:01:23.500 Except that both raw sockets, and the
00:01:26.300 native kernel interfaces, both require programs that
00:01:29.366 access them to run with administrator privileges.
00:01:32.433 This is a security risk, and prevents
00:01:35.066 those programs from being uploaded to the
00:01:37.033 relevant app stores.
00:01:39.500 This makes such programs, even if they
00:01:42.666 could be implemented, difficult to deploy.
00:01:45.466 On the other hand, writing user space
00:01:48.666 applications that run over UDP, using the
00:01:50.933 portable Berkeley Sockets API, or Windows Sockets,
00:01:54.066 is straightforward.
00:01:56.000 The same API works everywhere. The programming
00:01:59.366 model is widely understood. And there’s no
00:02:01.900 need for privileged access, so the programs
00:02:04.966 are easy to distribute and install.
00:02:07.900 It’s much easier, and more portable,
00:02:10.166 to run QUIC over UDP than natively
00:02:13.266 over IP.
00:02:16.500 The second reason for running QUIC over
00:02:19.233 UDP is protocol ossification.
00:02:21.466 Almost every home and business that connects
00:02:23.633 to the Internet does so via a
00:02:25.833 NAT or firewall. NAT devices know how
00:02:29.100 to find and translate the port numbers
00:02:31.533 in TCP and UDP headers. Firewalls know
00:02:34.833 how to inspect the headers and contents
00:02:37.300 of TCP connections and UDP packets.
00:02:40.066 And the same is true of all
00:02:42.400 the other proxies, gateways, and middleboxes in the network.
00:02:46.000 None of these understand QUIC.
00:02:48.433 If we run QUIC inside UDP packets,
00:02:51.766 there’s a chance it will work.
00:02:54.500 NATs can translate UDP packet headers without
00:02:57.233 inspecting the contents of those packets,
00:02:59.933 and many firewalls allow outgoing UDP traffic
00:03:03.666 to pass an establish an incoming firewall
00:03:06.400 pinhole, because this is needed for applications
00:03:08.966 like Zoom to work.
00:03:11.466 This wouldn’t be the case if QUIC
00:03:13.000 ran directly over IP. NATs wouldn’t know
00:03:16.333 how to translate the QUIC packets.
00:03:18.233 And firewalls tend to block anything that
00:03:20.200 isn’t TCP or UDP.
00:03:23.000 If we run QUIC over UDP,
00:03:25.400 it will probably work across the Internet
00:03:27.100 today. But if we run it directly
00:03:29.733 over IP, then we’d have to update
00:03:31.833 every firewall and NAT before it would
00:03:34.533 work – an essentially impossible task.
00:03:39.433 This is another example of protocol ossification.
00:03:43.133 Information that’s visible in the packet headers
00:03:46.266 or payload, that’s not encrypted and authenticated,
00:03:49.433 can be inspected and modified by devices
00:03:51.366 in the network.
00:03:54.000 This means that NATs and firewalls can
00:03:56.200 inspect the contents of IP packets.
00:03:58.700 They can tell whether those packets contain
00:04:01.133 TCP, UDP, or something else. This is
00:04:04.300 possible because the IP header and payload
00:04:06.600 are not encrypted.
00:04:09.000 Similarly, because the contents of those IP
00:04:12.300 packets are not authenticated, these NATs,
00:04:15.133 firewalls, and other devices can modify the packets.
00:04:18.566 This means we can buy NAT boxes
00:04:21.000 that modify the packets. That change the
00:04:23.333 IP, TCP, and UDP packet headers to
00:04:25.866 allow several devices to share an IP address.
00:04:28.900 It means we can buy firewalls that
00:04:30.866 inspect network packets and claim to protect
00:04:33.000 us from malware.
00:04:34.733 And it means we can buy all
00:04:36.066 the other proxies, caches, and other devices
00:04:38.400 that inspect and modify traffic in the network.
00:04:42.100 But maybe we don’t want the network
00:04:44.300 to read or modify our data.
00:04:47.033 So we use TLS to protect the
00:04:49.333 data we send within TCP connections.
00:04:51.700 Or datagram TLS, that does the same
00:04:54.433 for data sent within UDP packets.
00:04:57.100 And that works.
00:05:00.000 But what it doesn’t do, though,
00:05:02.000 is stop those devices inspecting and modifying
00:05:04.533 the TCP and UDP packet headers.
00:05:07.366 And it doesn’t stop them looking at
00:05:09.466 the IP packets, and deciding to block
00:05:11.633 them because the contents are not TCP
00:05:13.433 or UDP. Or because the TCP or
00:05:16.133 UDP header doesn’t exactly match their understanding
00:05:19.233 of how it should be formatted.
00:05:22.000 This means protocols like QUIC have to
00:05:24.566 hide inside UDP packets, to have a
00:05:26.700 chance of going through the network.
00:05:28.700 And it makes it harder to change
00:05:30.533 how TCP or UDP work.
00:05:33.600 We couldn’t change the format of the
00:05:35.766 TCP header now, for example, because too
00:05:38.533 many devices expect the existing format.
00:05:42.200 Similarly, it’s difficult to add even new
00:05:44.700 options to TCP packets, because too many
00:05:47.600 devices think they understand what options exist,
00:05:50.200 and fail when they see something unexpected.
00:05:54.866 The paper shown on the slide is
00:05:57.500 a study that tries to measure how
00:06:00.033 often firewalls and NATs block TCP packets
00:06:02.533 that include standardised but rarely used extensions.
00:06:05.066 And how often they block TCP packets
00:06:07.566 that use non-standard extensions, as you might
00:06:10.066 use when experimenting with changes to TCP.
00:06:12.766 It showed that TCP extensions were hard
00:06:15.100 to deploy. And while the results are
00:06:17.600 almost ten years old now, I doubt
00:06:20.133 it’s gotten easier to deploy changes to TCP.
00:06:25.000 Protocol ossification is becoming an increasing problem.
00:06:28.666 We’ve seen that it caused problems when
00:06:31.333 TLS 1.3 was being deployed. It causes
00:06:35.833 problems when trying to extend TCP.
00:06:38.166 And it was one of the reasons
00:06:40.066 why QUIC is designed to hide within
00:06:41.700 UDP packets.
00:06:44.000 Ossification is Increasingly viewed as a problem
00:06:46.466 by the standards community. It makes it
00:06:48.933 difficult to evolve network protocols to address
00:06:51.400 new requirements, and leads to the concern
00:06:53.866 that the network will get stuck.
00:06:56.133 That it’ll have known problems and limitations,
00:06:58.933 that we know how to solve,
00:07:00.533 but where we can’t deploy the fix.
00:07:05.633 The designers of QUIC went to great
00:07:07.700 lengths to make QUIC deployable, and to
00:07:09.766 prevent it from becoming ossified.
00:07:12.800 Running over UDP was the first of these.
00:07:15.900 And there are three more techniques they
00:07:18.133 used: they published the protocol invariants;
00:07:21.266 they make use of pervasive encryption of
00:07:23.600 transport headers; and they make use of GREASE.
00:07:28.033 The goal is to make it difficult,
00:07:30.100 and ideally impossible, for middleboxes to interfere
00:07:33.233 with QUIC connections. That is, a network
00:07:36.600 can allow QUIC traffic, or it can
00:07:38.800 block it entirely.
00:07:40.600 But it can’t inspect or modify QUIC
00:07:42.700 flows, apart from the invariant features.
00:07:48.766 The QUIC invariants are the properties of
00:07:50.833 QUIC that the IETF has indicated will never change.
00:07:54.733 The developers of QUIC, and the IETF
00:07:57.300 standards community, have written down a set
00:07:59.800 of properties of QUIC packets that they
00:08:02.066 guarantee will be true for every QUIC
00:08:04.300 packet, for all time, and for all versions.
00:08:06.866 These are the properties that middleboxes,
00:08:09.100 NATs, and firewalls are allowed to inspect.
00:08:12.533 Anything else, the IETF has said,
00:08:15.233 is subject to change in future versions of QUIC.
00:08:19.700 What are those invariants?
00:08:22.466 That QUIC packets will either start with
00:08:25.000 a long header or a short header.
00:08:27.166 There will be no other header formats.
00:08:29.866 That the first bit of the first
00:08:31.566 byte of a long header packet is
00:08:33.233 set to one. That bytes 2-5 of
00:08:36.333 a long header packet contain a version
00:08:38.133 number. And the following that version number
00:08:40.933 are the destination connection identifier then the
00:08:43.200 source connection identifier.
00:08:45.833 And for short header packets, that the
00:08:48.366 first bit of the first byte is
00:08:49.900 always zero. And that the first byte
00:08:52.466 is followed by the destination connection identifier.
00:08:56.000 And that’s it.
00:08:58.600 A QUIC version 1 connection starts with
00:09:01.633 a connection establishment handshake, sent in long
00:09:04.266 header packets, then the connection switches to
00:09:06.900 use short header packets, but there is
00:09:09.533 no guarantee that future versions will do the same.
00:09:12.533 QUIC version 1 defines the format of
00:09:14.833 the other 7 bits of the first
00:09:16.766 byte, but there’s no guarantee that future
00:09:19.100 versions of QUIC won’t change that meaning.
00:09:22.800 And QUIC makes no guarantees about the
00:09:24.600 contents of the packets following the
00:09:26.133 connection identifiers.
00:09:30.000 Now, of course, writing a standard that
00:09:32.566 says “middleboxes MUST NOT look at these
00:09:34.500 fields in QUIC packets” doesn’t stop middleboxes
00:09:37.166 looking at those fields.
00:09:40.033 Accordingly, QUIC applies two other techniques to
00:09:43.066 make sure middleboxes can’t inspect its packets.
00:09:47.133 The first is that QUIC encrypts as
00:09:49.166 much of its packets as possible.
00:09:52.200 Everything except the invariant fields, and the
00:09:55.533 last 7 bits of the first byte
00:09:57.300 of the packet, is encrypted. This makes
00:10:00.100 it impossible for middleboxes to inspect any
00:10:02.533 part of a QUIC header after the
00:10:04.066 connection identifiers.
00:10:07.000 Since QUIC incorporates TLS, this is straightforward
00:10:09.966 to do for most packets.
00:10:12.066 An encryption key is agreed using connection
00:10:14.333 establishment, and this is used to encrypt
00:10:16.500 the packets.
00:10:18.533 What about the connection establishment packets themselves?
00:10:21.133 How are they encrypted?
00:10:23.533 Well, these contain the public keys,
00:10:25.633 which are supposed to be public,
00:10:27.500 so they don’t actually need to be
00:10:29.066 encrypted. TLS over TCP doesn’t encrypt these
00:10:33.100 packets, for example. But QUIC encrypts them anyway.
00:10:38.333 So, what encryption key does it use?
00:10:41.266 Well, it can’t use a TLS key,
00:10:43.800 since these packets are sent before the
00:10:46.166 TLS handshake is completed. And it can’t
00:10:48.533 use a PreSharedKey, because this might be
00:10:50.866 the first time the client and server have communicated.
00:10:54.033 What it does, is to take the
00:10:55.600 connection identifiers from the long header in
00:10:57.733 the connection establishment packets, and use them
00:11:00.333 as the encryption key to encrypt the
00:11:01.866 rest of the packet.
00:11:05.000 On the face of it, this offers no benefit.
00:11:09.000 It certainly doesn’t provide any security.
00:11:11.600 The encryption key for the connection establishment
00:11:14.466 packet is included, unprotected, at the start
00:11:16.300 of the packet.
00:11:18.600 That is doesn’t provide security doesn’t matter,
00:11:20.700 though, since there’s nothing secret in the
00:11:22.566 connection establishment packets.
00:11:25.200 What is does do, is make the
00:11:26.966 middlebox implementors think.
00:11:30.000 You can build a TCP middlebox by
00:11:32.600 running a tool like wireshark or tcpdump,
00:11:35.200 and looking at the packets as they
00:11:37.800 go by. Everything is visible, and the
00:11:40.400 patterns of how the headers changes,
00:11:42.466 in the common cases, are obvious.
00:11:44.800 You can get away without reading the
00:11:46.433 TCP specification at all, and still build
00:11:49.066 a middlebox that sort-of works.
00:11:51.833 Of course it doesn’t really work,
00:11:53.433 and causes problems when people try to
00:11:55.400 do uncommon things with TCP. But it
00:11:57.833 works for the simple cases.
00:12:00.166 You can’t do that with QUIC.
00:12:02.566 Everything appears to be encrypted.
00:12:04.933 You have the read and understand the
00:12:07.633 QUIC specification to realise that the handshake
00:12:09.766 packets are encrypted in a way that
00:12:11.300 lets you easily decrypt them. Otherwise,
00:12:13.600 you get nothing useful.
00:12:17.300 QUIC also makes extensive use of GREASE.
00:12:20.866 It makes sure that every field in
00:12:22.900 a QUIC packet is either encrypted,
00:12:25.000 or has a value that is,
00:12:26.666 at least sometimes, unpredictable.
00:12:29.733 The connection identifiers are randomly chosen at
00:12:32.200 the start of a connection.
00:12:34.500 QUIC clients will randomly try to negotiate
00:12:37.233 a random version number, that the server
00:12:39.866 will reject, to make sure devices in
00:12:42.500 the network don’t get stuck only supporting
00:12:44.400 version one.
00:12:46.000 And any unused fields in the headers
00:12:48.100 are set to random values.
00:12:51.000 This goal is that middleboxes can’t make
00:12:53.233 any assumptions about QUIC header values,
00:12:55.133 because nothing in the header is predictable.
00:12:58.666 The hope is that this avoids ossification.
00:13:01.566 There are no patterns to the header
00:13:03.366 values, so middleboxes can’t make wrong assumptions
00:13:05.933 about how the headers behave that will
00:13:07.633 cause problems later.
00:13:10.633 Will it work? Will it prevent ossification?
00:13:14.033 We don’t know.
00:13:15.466 Ask me again in a few years.
00:13:20.500 That concludes this introduction
00:13:22.166 to the QUIC transport protocol.
00:13:24.600 Why might you want to use QUIC?
00:13:28.000 Because it can speed-up secure connection establishment;
00:13:31.133 because it solves some of the limitations
00:13:34.266 of TLS 1.3 running over TCP;
00:13:36.766 and because it supports sending multiple streams
00:13:38.833 within a single connection.
00:13:41.633 And because it, hopefully, reduces risk of
00:13:44.100 ossification, and provides a long-term basis for
00:13:46.833 future protocol development.
00:13:50.300 That said, QUIC is new. The standard
00:13:53.700 hasn’t yet been published, and we don’t
00:13:55.900 have a lot of experience with using
00:13:57.633 the protocol.
00:13:59.366 And while there are many implementations of
00:14:01.500 QUIC, in many different languages, they’re all
00:14:04.500 still immature, poorly documented, and frequently buggy.
00:14:08.466 And QUIC is often, currently, slower,
00:14:11.066 and uses more CPU, than TLS over TCP.
00:14:15.933 This is not because of inherent limitations
00:14:18.066 of QUIC. Rather, it’s because the TCP
00:14:21.433 implementations have had 40 years more optimisation
00:14:24.633 and debugging time.
00:14:27.000 When the implementations are finished, debugged,
00:14:29.366 and optimised, QUIC ought to perform at
00:14:31.800 least as well as, and probably significantly
00:14:34.300 better than TCP. And it should be
00:14:37.633 more secure and easier to extend.
00:14:40.500 TCP lasted 40 years – QUIC is
00:14:44.666 a similarly long-term project, that’s only just
00:14:46.933 reaching version 1.0.
00:14:50.600 That’s all for this lecture. I’ve spoken
00:14:53.533 about some of the limitations of TLS,
00:14:55.466 and how the QUIC transport protocol tries
00:14:57.366 to address them.
00:14:58.966 In the next lecture, I’ll move on
00:15:00.800 from connection establishment,
00:15:02.333 to talk about reliability and data transfer.
Lecture 4 discussed how to improve secure connection establishment. It started with a discussion of some of the limitations of TLS 1.3, how 0-RTT connection re-establishment can be used to reduce connection setup latency, and some of the metadata leakage inherent in TLS. It then moved on to discuss the QUIC transport protocol, and how QUIC can be used to improve secure connection establishment.
The focus of the discussion will be to check your understanding of secure connection establishment and its limitations. What are the risks and benefits of 0-RTT mode in TLS? What is the nature of the privacy guarantees TLS provides?
And how does QUIC improve on TLS and TCP, to reduce connection setup latency and reduce the risk of ossification? How does it improve on the TCP and TLS service model?