csperkins.org

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.

Slides for part 1

 

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:52.900 Yes.

 

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:05.833 negotiated?

 

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:34.000 But.

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:15.033 connections.

 

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.

Slides for part 2

 

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.

Slides for part 3

 

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:50.466 round-trip.

 

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.

Slides for part 4

 

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.

Discussion

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?