Colin Perkins

 

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.

 

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.

 

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.

 

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.