[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:14.82,Default,,0000,0000,0000,,{\i1}33C3 preroll music{\i0}
Dialogue: 0,0:00:14.82,0:00:20.19,Default,,0000,0000,0000,,Herald: Basically the upcoming\Ntalk is about “Deploying TLS 1.3”
Dialogue: 0,0:00:20.19,0:00:23.51,Default,,0000,0000,0000,,and is by Filippo Valsorda\Nand Nick Sullivan,
Dialogue: 0,0:00:23.51,0:00:26.99,Default,,0000,0000,0000,,and they’re both with Cloudflare.
Dialogue: 0,0:00:26.99,0:00:32.11,Default,,0000,0000,0000,,So please, a warm welcome\Nto Nick and Filippo!
Dialogue: 0,0:00:32.11,0:00:39.49,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:00:39.49,0:00:43.82,Default,,0000,0000,0000,,Filippo: Hello everyone. Alright,\Nwe are here to talk about TLS 1.3.
Dialogue: 0,0:00:43.82,0:00:48.34,Default,,0000,0000,0000,,TLS 1.3 is of course the latest\Nversion of TLS, which stands for
Dialogue: 0,0:00:48.34,0:00:52.96,Default,,0000,0000,0000,,‘Transport Layer Security’.\NNow, you might know it best
Dialogue: 0,0:00:52.96,0:00:57.90,Default,,0000,0000,0000,,as, of course, the green lock in\Nthe browser, or by its old name SSL,
Dialogue: 0,0:00:57.90,0:01:02.51,Default,,0000,0000,0000,,which we are still trying\Nto kill. Now. TLS is
Dialogue: 0,0:01:02.51,0:01:07.89,Default,,0000,0000,0000,,a transparent security protocol\Nthat can tunnel securely
Dialogue: 0,0:01:07.89,0:01:12.46,Default,,0000,0000,0000,,arbitrary application traffic.\NIt’s used by web browsers, of course,
Dialogue: 0,0:01:12.46,0:01:16.76,Default,,0000,0000,0000,,it’s used by mail servers to\Ncommunicate with each other
Dialogue: 0,0:01:16.76,0:01:22.27,Default,,0000,0000,0000,,to secure SMTP. It’s used by\NTor nodes to talk to each other.
Dialogue: 0,0:01:22.27,0:01:26.81,Default,,0000,0000,0000,,But it evolved over 20 years,
Dialogue: 0,0:01:26.81,0:01:31.32,Default,,0000,0000,0000,,but at its core it’s about a client\Nand a server that want to communicate
Dialogue: 0,0:01:31.32,0:01:36.12,Default,,0000,0000,0000,,securely over the network.\NTo communicate securely over the network
Dialogue: 0,0:01:36.12,0:01:41.17,Default,,0000,0000,0000,,they need to establish some key material,\Nto agree on some key material
Dialogue: 0,0:01:41.17,0:01:47.35,Default,,0000,0000,0000,,on the two sides to encrypt\Nthe rest of the traffic.
Dialogue: 0,0:01:47.35,0:01:51.99,Default,,0000,0000,0000,,Now how they agree on this key material\Nis [done] in a phase that we call
Dialogue: 0,0:01:51.99,0:01:57.89,Default,,0000,0000,0000,,the ‘handshake’. The handshake involves\Nsome public key cryptography and some data
Dialogue: 0,0:01:57.89,0:02:02.67,Default,,0000,0000,0000,,being shovelled from the client to the\Nserver, from the server to the client.
Dialogue: 0,0:02:02.67,0:02:07.17,Default,,0000,0000,0000,,Now this is how the handshake\Nlooks like in TLS 1.2.
Dialogue: 0,0:02:07.17,0:02:12.79,Default,,0000,0000,0000,,So the client starts the dances\Nby sending a ‘Client Hello’ over,
Dialogue: 0,0:02:12.79,0:02:18.96,Default,,0000,0000,0000,,which specifies what supported\Nparameters it can use.
Dialogue: 0,0:02:18.96,0:02:23.43,Default,,0000,0000,0000,,The server receives that and sends\Na message of its own, which is
Dialogue: 0,0:02:23.43,0:02:28.20,Default,,0000,0000,0000,,‘Server Hello’ that says: “Sure!\NLet’s use this cipher suite over here
Dialogue: 0,0:02:28.20,0:02:33.23,Default,,0000,0000,0000,,that you say you support, and\Nhere is my key share to be used
Dialogue: 0,0:02:33.23,0:02:39.27,Default,,0000,0000,0000,,in this key agreement algorithm.\NAnd also here is a certificate
Dialogue: 0,0:02:39.27,0:02:45.30,Default,,0000,0000,0000,,which is signed by an authority\Nthat proves that I am indeed
Dialogue: 0,0:02:45.30,0:02:50.37,Default,,0000,0000,0000,,Cloudflare.com. And here is a signature\Nfrom the certificate to prove that
Dialogue: 0,0:02:50.37,0:02:55.45,Default,,0000,0000,0000,,this key share is actually the one that\NI want you to use, to establish keys”.
Dialogue: 0,0:02:55.45,0:03:00.94,Default,,0000,0000,0000,,The client receives that, and it generates\Nits own key share, its own half
Dialogue: 0,0:03:00.94,0:03:06.20,Default,,0000,0000,0000,,of the Diffie-Hellman key exchange,\Nand sends over the key share,
Dialogue: 0,0:03:06.20,0:03:10.100,Default,,0000,0000,0000,,and a message to say: “Alright, this\Nis it. This wraps up the handshake”
Dialogue: 0,0:03:10.100,0:03:15.49,Default,,0000,0000,0000,,which is called the ‘Finished’ message.\N[The] server receives that, makes
Dialogue: 0,0:03:15.49,0:03:20.68,Default,,0000,0000,0000,,a ‘Finished’ message of its own,\Nand answers with that. So.
Dialogue: 0,0:03:20.68,0:03:25.93,Default,,0000,0000,0000,,Now we can finally send application\Ndata. So to recap, we went:
Dialogue: 0,0:03:25.93,0:03:30.02,Default,,0000,0000,0000,,Client –> Server, Server –> Client;\NClient –> Server, Server –> Client.
Dialogue: 0,0:03:30.02,0:03:34.96,Default,,0000,0000,0000,,We had to do 2 round trips between the\Nclient and the server before we could do
Dialogue: 0,0:03:34.96,0:03:40.73,Default,,0000,0000,0000,,anything. We haven’t sent any\Nbyte on the application layer
Dialogue: 0,0:03:40.73,0:03:46.01,Default,,0000,0000,0000,,until now. Now of course\Nthis, on mobile networks
Dialogue: 0,0:03:46.01,0:03:50.54,Default,,0000,0000,0000,,or in certain parts of the\Nworld, can build up
Dialogue: 0,0:03:50.54,0:03:55.32,Default,,0000,0000,0000,,to hundreds of milliseconds of latency.\NAnd this is what needs to happen
Dialogue: 0,0:03:55.32,0:04:00.93,Default,,0000,0000,0000,,every time a new connection is set up.\NEvery time the client and the server
Dialogue: 0,0:04:00.93,0:04:06.49,Default,,0000,0000,0000,,have to go twice between them\Nto establish the keys before
Dialogue: 0,0:04:06.49,0:04:12.73,Default,,0000,0000,0000,,the connection can actually\Nbe used. Now, TLS 1.1
Dialogue: 0,0:04:12.73,0:04:17.95,Default,,0000,0000,0000,,and 1.0 were not that different\Nfrom 1.2. So you might ask: well, then
Dialogue: 0,0:04:17.95,0:04:23.75,Default,,0000,0000,0000,,why are we having an entire talk on\NTLS 1.3, which is probably just this other
Dialogue: 0,0:04:23.75,0:04:31.43,Default,,0000,0000,0000,,iteration over the same concept? Well,\NTLS 1.3 is actually a big re-design.
Dialogue: 0,0:04:31.43,0:04:36.74,Default,,0000,0000,0000,,And in particular, the handshake has been\Nrestructured. And the most visible result
Dialogue: 0,0:04:36.74,0:04:43.14,Default,,0000,0000,0000,,of this is that an entire round\Ntrip has been shaved off.
Dialogue: 0,0:04:43.14,0:04:48.93,Default,,0000,0000,0000,,So, here is how a TLS 1.3\Nhandshake looks like.
Dialogue: 0,0:04:48.93,0:04:53.48,Default,,0000,0000,0000,,How does 1.3 remove a round trip?\NHow can it do that? Well, it does that
Dialogue: 0,0:04:53.48,0:04:59.80,Default,,0000,0000,0000,,by predicting what key agreement algorithm
Dialogue: 0,0:04:59.80,0:05:04.74,Default,,0000,0000,0000,,the server will decide to use, and\Nsending pre-emptively a key share
Dialogue: 0,0:05:04.74,0:05:10.03,Default,,0000,0000,0000,,for that algorithm to the server.\NSo with the first flight we had
Dialogue: 0,0:05:10.03,0:05:15.53,Default,,0000,0000,0000,,the ‘Client Hello’, the supported\Nparameters, and a key share
Dialogue: 0,0:05:15.53,0:05:21.55,Default,,0000,0000,0000,,for the one that the client thinks the\Nserver will like. The server receives that
Dialogue: 0,0:05:21.55,0:05:27.24,Default,,0000,0000,0000,,and if everything goes well, it will\Ngo like “Oh! Sure! I like this key share.
Dialogue: 0,0:05:27.24,0:05:32.79,Default,,0000,0000,0000,,Here is my own key share to run\Nthe same algorithm, and here is
Dialogue: 0,0:05:32.79,0:05:37.72,Default,,0000,0000,0000,,the other parameters we should use.”\NIt immediately mixes the two key shares
Dialogue: 0,0:05:37.72,0:05:42.32,Default,,0000,0000,0000,,to get a shared key, because now\Nit has both key shares – the client’s
Dialogue: 0,0:05:42.32,0:05:47.09,Default,,0000,0000,0000,,and the server’s – and sends again\Nthe certificate and a signature
Dialogue: 0,0:05:47.09,0:05:51.34,Default,,0000,0000,0000,,from the certificate, and then\Nimmediately sends a ‘Finished’ message
Dialogue: 0,0:05:51.34,0:05:56.34,Default,,0000,0000,0000,,because it doesn’t need anything else\Nfrom the client. The client receives that,
Dialogue: 0,0:05:56.34,0:06:02.02,Default,,0000,0000,0000,,takes the key share, mixes the shared key\Nand sends its own ‘Finished’ message,
Dialogue: 0,0:06:02.02,0:06:07.01,Default,,0000,0000,0000,,and is ready to send whatever application\Nlayer data it was waiting to send.
Dialogue: 0,0:06:07.01,0:06:12.65,Default,,0000,0000,0000,,For example your HTTP\Nrequest. Now we went:
Dialogue: 0,0:06:12.65,0:06:15.92,Default,,0000,0000,0000,,Client –> Server, Server –> Client.
Dialogue: 0,0:06:15.92,0:06:21.33,Default,,0000,0000,0000,,And we are ready to send data at the\Napplication layer. So you are trying
Dialogue: 0,0:06:21.33,0:06:27.24,Default,,0000,0000,0000,,to setup a HTTPS connection\Nand your browser
Dialogue: 0,0:06:27.24,0:06:32.77,Default,,0000,0000,0000,,doesn’t need to wait 4x\Nthe latency, or 4x the ping.
Dialogue: 0,0:06:32.77,0:06:38.93,Default,,0000,0000,0000,,It only has to wait 2x. And of course\Nthis saves hundreds of milliseconds
Dialogue: 0,0:06:38.93,0:06:46.20,Default,,0000,0000,0000,,of latency when setting up fresh\Nconnections. Now, this is the happy path.
Dialogue: 0,0:06:46.20,0:06:52.30,Default,,0000,0000,0000,,So this is what happens when the\Nprediction is correct and the server likes
Dialogue: 0,0:06:52.30,0:06:58.45,Default,,0000,0000,0000,,the client key share. If the server\Ndoesn’t support the key share
Dialogue: 0,0:06:58.45,0:07:05.17,Default,,0000,0000,0000,,that the client sent it will send a polite\Nrequest to use a different algorithm
Dialogue: 0,0:07:05.17,0:07:10.53,Default,,0000,0000,0000,,that the client said it can support. We\Ncall that message ‘Hello Retry Request’.
Dialogue: 0,0:07:10.53,0:07:16.47,Default,,0000,0000,0000,,It has a cookie, so that can be stateless,\Nbut essentially it makes a fall-back
Dialogue: 0,0:07:16.47,0:07:21.97,Default,,0000,0000,0000,,to what is effectively a TLS-1.2-like\Nhandshake. And it’s not that hard
Dialogue: 0,0:07:21.97,0:07:26.94,Default,,0000,0000,0000,,to implement because the client follows up\Nwith a new ‘Client Hello’ which looks
Dialogue: 0,0:07:26.94,0:07:34.49,Default,,0000,0000,0000,,essentially exactly like a fresh one. Now.
Dialogue: 0,0:07:34.49,0:07:42.18,Default,,0000,0000,0000,,Here I’ve been lying to you.\NTLS 1.2 is not always 2 round trips.
Dialogue: 0,0:07:42.18,0:07:47.78,Default,,0000,0000,0000,,Most of the connections we see from the\NCloudflare edge e.g. are ‘resumptions’.
Dialogue: 0,0:07:47.78,0:07:53.30,Default,,0000,0000,0000,,That means that the client has connected\Nto that website before in the past.
Dialogue: 0,0:07:53.30,0:07:59.08,Default,,0000,0000,0000,,And we can use that, we can exploit\Nthat to make the handshake faster.
Dialogue: 0,0:07:59.08,0:08:06.29,Default,,0000,0000,0000,,That means that the client can remember\Nsomething about the key material
Dialogue: 0,0:08:06.29,0:08:10.96,Default,,0000,0000,0000,,to make the next connection\Na round trip even in TLS 1.2.
Dialogue: 0,0:08:10.96,0:08:16.02,Default,,0000,0000,0000,,So here is how it looks like. Here\Nyou have your normal TLS 1.2 full
Dialogue: 0,0:08:16.02,0:08:22.48,Default,,0000,0000,0000,,2-round trip connection. And over\Nhere it sends a new session ticket.
Dialogue: 0,0:08:22.48,0:08:30.03,Default,,0000,0000,0000,,A session ticket is nothing else than a\Nencrypted wrapped blob of key material
Dialogue: 0,0:08:30.03,0:08:35.10,Default,,0000,0000,0000,,that the client will hold on to. The\Nsession ticket is encrypted and signed
Dialogue: 0,0:08:35.10,0:08:40.04,Default,,0000,0000,0000,,with a key that only the server knows.\NSo it’s completely opaque to the client.
Dialogue: 0,0:08:40.04,0:08:45.04,Default,,0000,0000,0000,,But the client will keep it together\Nwith the key material of the connection,
Dialogue: 0,0:08:45.04,0:08:49.34,Default,,0000,0000,0000,,so that the next time it makes\Na connection to that same website
Dialogue: 0,0:08:49.34,0:08:54.44,Default,,0000,0000,0000,,it will send a ‘Client Hello’,\Nand a session ticket.
Dialogue: 0,0:08:54.44,0:08:59.18,Default,,0000,0000,0000,,If the server recognises the session\Nticket it will decrypt it, find inside
Dialogue: 0,0:08:59.18,0:09:04.09,Default,,0000,0000,0000,,the key material. And now, after only one\Nround trip, the server will have some
Dialogue: 0,0:09:04.09,0:09:09.82,Default,,0000,0000,0000,,shared key material with the client because\Nthe client held on to the key material
Dialogue: 0,0:09:09.82,0:09:15.46,Default,,0000,0000,0000,,from last time and the server just\Ndecrypted it from the session ticket.
Dialogue: 0,0:09:15.46,0:09:20.89,Default,,0000,0000,0000,,OK? So now the server has some shared\Nkeys to use already, and it sends
Dialogue: 0,0:09:20.89,0:09:26.15,Default,,0000,0000,0000,,a ‘Finished’ message, and the client sends\Nits own ‘Finished’ message and the request.
Dialogue: 0,0:09:26.15,0:09:31.55,Default,,0000,0000,0000,,So this is TLS 1.2. This is what\Nis already happening every day
Dialogue: 0,0:09:31.55,0:09:37.38,Default,,0000,0000,0000,,with most modern TLS connections. Now.
Dialogue: 0,0:09:37.38,0:09:43.53,Default,,0000,0000,0000,,TLS 1.3 resumption is not that different.\NIt still has the concept of a session ticket.
Dialogue: 0,0:09:43.53,0:09:48.30,Default,,0000,0000,0000,,We changed the name of what’s inside\Nthe session ticket to a ‘PSK’ but that
Dialogue: 0,0:09:48.30,0:09:53.22,Default,,0000,0000,0000,,just means ‘Pre-shared Key’ because\Nthat’s what it is: it’s some key material
Dialogue: 0,0:09:53.22,0:09:58.48,Default,,0000,0000,0000,,that was agreed upon in advance.\NAnd it works the same way:
Dialogue: 0,0:09:58.48,0:10:02.83,Default,,0000,0000,0000,,the server receives the session\Nticket, decrypts it and jumps to the
Dialogue: 0,0:10:02.83,0:10:07.45,Default,,0000,0000,0000,,‘Finished’ message. Now,
Dialogue: 0,0:10:07.45,0:10:13.07,Default,,0000,0000,0000,,a problem with resumption\Nis that if an attacker
Dialogue: 0,0:10:13.07,0:10:17.13,Default,,0000,0000,0000,,controls the session ticket key\N– the key that the server uses
Dialogue: 0,0:10:17.13,0:10:21.54,Default,,0000,0000,0000,,to encrypt the session ticket that\Nhas inside the key material –
Dialogue: 0,0:10:21.54,0:10:27.05,Default,,0000,0000,0000,,an attacker can passively or in the future\Neven, with a recording of the connection,
Dialogue: 0,0:10:27.05,0:10:33.46,Default,,0000,0000,0000,,decrypt the session ticket from the\N‘Client Hello’, find the PSK inside it
Dialogue: 0,0:10:33.46,0:10:38.32,Default,,0000,0000,0000,,and use it to decrypt the rest of\Nthe connection. This is not good.
Dialogue: 0,0:10:38.32,0:10:42.52,Default,,0000,0000,0000,,This means that someone can do\Npassive decryption by just having
Dialogue: 0,0:10:42.52,0:10:47.82,Default,,0000,0000,0000,,the session ticket key. How this is\Naddressed usually is that we say
Dialogue: 0,0:10:47.82,0:10:52.54,Default,,0000,0000,0000,,that session ticket keys are short-\Nlived. But still it would be nice if
Dialogue: 0,0:10:52.54,0:10:56.27,Default,,0000,0000,0000,,we didn’t have to rely on that. And there\Nare actually nice papers that tell us
Dialogue: 0,0:10:56.27,0:11:01.31,Default,,0000,0000,0000,,that implementations don’t\Nalways do this right. So,
Dialogue: 0,0:11:01.31,0:11:07.05,Default,,0000,0000,0000,,instead what TLS 1.3 allows\Nus to do is use Diffie-Hellman
Dialogue: 0,0:11:07.05,0:11:11.76,Default,,0000,0000,0000,,with resumption. In 1.2 there\Nwas no way to protect
Dialogue: 0,0:11:11.76,0:11:16.72,Default,,0000,0000,0000,,against session ticket key\Ncompromise. In 1.3 what you can do
Dialogue: 0,0:11:16.72,0:11:21.41,Default,,0000,0000,0000,,is send a key share as part\Nof the ‘Client Hello’ anyway,
Dialogue: 0,0:11:21.41,0:11:25.50,Default,,0000,0000,0000,,and the server will send a key share\Ntogether with the ‘Server Hello’,
Dialogue: 0,0:11:25.50,0:11:31.71,Default,,0000,0000,0000,,and they will run Diffie-Hellman.\NDiffie-Hellman is what was used to
Dialogue: 0,0:11:31.71,0:11:36.01,Default,,0000,0000,0000,,introduce forward secrecy against\Nthe compromise of, for example,
Dialogue: 0,0:11:36.01,0:11:41.34,Default,,0000,0000,0000,,the certificate private key in 1.2, and\Nit’s used here to provide forward secrecy
Dialogue: 0,0:11:41.34,0:11:46.29,Default,,0000,0000,0000,,for resumed connections.\NNow, you will say:
Dialogue: 0,0:11:46.29,0:11:51.24,Default,,0000,0000,0000,,“Now this looks essentially\Nlike a normal 1.3 handshake,
Dialogue: 0,0:11:51.24,0:11:55.77,Default,,0000,0000,0000,,why having the PSK at all?” Well,\Nthere is something missing from this one,
Dialogue: 0,0:11:55.77,0:11:59.51,Default,,0000,0000,0000,,there is no certificate. Because\Nthere is no need to re-authenticate
Dialogue: 0,0:11:59.51,0:12:04.62,Default,,0000,0000,0000,,with a certificate because the client and\Nthe server spoke in the past, and so
Dialogue: 0,0:12:04.62,0:12:09.10,Default,,0000,0000,0000,,the client knows that it already checked\Nthe certificate of the server and
Dialogue: 0,0:12:09.10,0:12:12.82,Default,,0000,0000,0000,,if the server can decrypt the session\Nticket it means that it’s actually
Dialogue: 0,0:12:12.82,0:12:17.88,Default,,0000,0000,0000,,who it says it is. So, the two\Nkey shares get mixed together.
Dialogue: 0,0:12:17.88,0:12:22.86,Default,,0000,0000,0000,,Then mixed with the PSK to make\Na key that encrypts the rest
Dialogue: 0,0:12:22.86,0:12:29.58,Default,,0000,0000,0000,,of the connection. Now.\NThere is one other feature
Dialogue: 0,0:12:29.58,0:12:34.70,Default,,0000,0000,0000,,that is introduced by TLS 1.3\Nresumption. And that is the fact
Dialogue: 0,0:12:34.70,0:12:40.83,Default,,0000,0000,0000,,that it allows us to make 0-round\Ntrip handshakes. Again,
Dialogue: 0,0:12:40.83,0:12:47.28,Default,,0000,0000,0000,,all handshakes in 1.3\Nare mostly 1-round trip.
Dialogue: 0,0:12:47.28,0:12:52.14,Default,,0000,0000,0000,,TLS 1.2 resumptions can be\Nat a minimum 1-round trip.
Dialogue: 0,0:12:52.14,0:12:58.33,Default,,0000,0000,0000,,TLS 1.3 resumptions can be 0-round\Ntrip. How does a 0-round trip
Dialogue: 0,0:12:58.33,0:13:04.21,Default,,0000,0000,0000,,handshake work? Well, if you think about\Nit, when you start, you have a PSK,
Dialogue: 0,0:13:04.21,0:13:10.12,Default,,0000,0000,0000,,a Pre-Shared Key. The client\Ncan just use that to encrypt
Dialogue: 0,0:13:10.12,0:13:15.68,Default,,0000,0000,0000,,this early data that it wants to\Nsend to the server. So the client
Dialogue: 0,0:13:15.68,0:13:20.44,Default,,0000,0000,0000,,opens a connection, to a server that it\Nhas already connected to in the past,
Dialogue: 0,0:13:20.44,0:13:25.35,Default,,0000,0000,0000,,and sends ‘Client Hello’, session ticket,
Dialogue: 0,0:13:25.35,0:13:29.92,Default,,0000,0000,0000,,key share for Diffie-Hellman and\Nthen early data. Early data is
Dialogue: 0,0:13:29.92,0:13:34.41,Default,,0000,0000,0000,,this blob of application data\N– it can be e.g. a HTTP request –
Dialogue: 0,0:13:34.41,0:13:39.41,Default,,0000,0000,0000,,encrypted with the PSK.\NThe server receives this,
Dialogue: 0,0:13:39.41,0:13:45.37,Default,,0000,0000,0000,,decrypts the session ticket, finds\Nthe PSK, uses the PSK to decrypt the
Dialogue: 0,0:13:45.37,0:13:50.77,Default,,0000,0000,0000,,early data and then proceeds as normal:\Nmixes the 2 key shares, mixes the PSK in,
Dialogue: 0,0:13:50.77,0:13:55.27,Default,,0000,0000,0000,,makes a new key for the rest of the\Nconnection and continues the connection.
Dialogue: 0,0:13:55.27,0:14:00.29,Default,,0000,0000,0000,,So what happened here? We were able to\Nsend application data immediately upon
Dialogue: 0,0:14:00.29,0:14:05.34,Default,,0000,0000,0000,,opening the connection. This means that\Nwe completely removed the performance
Dialogue: 0,0:14:05.34,0:14:11.32,Default,,0000,0000,0000,,overhead of TLS. Now.
Dialogue: 0,0:14:11.32,0:14:16.46,Default,,0000,0000,0000,,0-RTT handshakes, though, have\N2 caveats that are theoretically
Dialogue: 0,0:14:16.46,0:14:22.54,Default,,0000,0000,0000,,impossible to remove. One is that\Nthat nice thing that we introduced
Dialogue: 0,0:14:22.54,0:14:27.83,Default,,0000,0000,0000,,with the PSK ECDHE mode, the one where\Nwe do Diffie-Hellman for resumption
Dialogue: 0,0:14:27.83,0:14:33.04,Default,,0000,0000,0000,,in 1.3, does not help with 0-RTT data.
Dialogue: 0,0:14:33.04,0:14:38.62,Default,,0000,0000,0000,,We do Diffie-Hellman when we\Nreach the green box in the slide.
Dialogue: 0,0:14:38.62,0:14:44.00,Default,,0000,0000,0000,,Of course the early data is only encrypted\Nwith the PSK. So let’s think about
Dialogue: 0,0:14:44.00,0:14:49.15,Default,,0000,0000,0000,,the attacker again. The attacker somehow\Nstole our session ticket encryption keys.
Dialogue: 0,0:14:49.15,0:14:54.97,Default,,0000,0000,0000,,It can look at the ‘Client Hello’, decrypt\Nthe session ticket, get the PSK out,
Dialogue: 0,0:14:54.97,0:15:00.03,Default,,0000,0000,0000,,use the PSK to decrypt the early data.
Dialogue: 0,0:15:00.03,0:15:05.35,Default,,0000,0000,0000,,And it can do this even from a recording\Nif it gets the session ticket later on.
Dialogue: 0,0:15:05.35,0:15:11.52,Default,,0000,0000,0000,,So the early data is not forward secret\Nwith respect to the session ticket keys.
Dialogue: 0,0:15:11.52,0:15:16.68,Default,,0000,0000,0000,,Then of course it becomes useless\Nif we are doing Diffie-Hellman to get
Dialogue: 0,0:15:16.68,0:15:23.02,Default,,0000,0000,0000,,the server answer. That’s only useful\Nfor the first flight sent from the client.
Dialogue: 0,0:15:23.02,0:15:28.34,Default,,0000,0000,0000,,So to recap, a lot of things\Ngoing on here: TLS 1.2
Dialogue: 0,0:15:28.34,0:15:33.38,Default,,0000,0000,0000,,introduced forward secrecy\Nagainst the compromise of the
Dialogue: 0,0:15:33.38,0:15:39.12,Default,,0000,0000,0000,,certificate private keys, a long\Ntime ago, by using ECDHE modes.
Dialogue: 0,0:15:39.12,0:15:45.03,Default,,0000,0000,0000,,So 1.2 connections can be\Nalways forward secret against
Dialogue: 0,0:15:45.03,0:15:50.30,Default,,0000,0000,0000,,certificate compromise.\NTLS 1.3 has that always on as well.
Dialogue: 0,0:15:50.30,0:15:55.09,Default,,0000,0000,0000,,There is no mode that is not forward\Nsecret against compromise of the
Dialogue: 0,0:15:55.09,0:16:01.28,Default,,0000,0000,0000,,certificate. But when we think about what\Nmight happen to the session ticket key:
Dialogue: 0,0:16:01.28,0:16:06.00,Default,,0000,0000,0000,,TLS 1.2 never provides forward secrecy.
Dialogue: 0,0:16:06.00,0:16:11.15,Default,,0000,0000,0000,,In TLS 1.2 compromising the session\Nticket key always means being able
Dialogue: 0,0:16:11.15,0:16:15.82,Default,,0000,0000,0000,,to passively and in the future\Ndecrypt resumed connections.
Dialogue: 0,0:16:15.82,0:16:22.69,Default,,0000,0000,0000,,In 1.3 instead, if we use PSK\NECDHE only the early data
Dialogue: 0,0:16:22.69,0:16:28.27,Default,,0000,0000,0000,,can be decrypted by using\Nthe session ticket key alone.
Dialogue: 0,0:16:28.27,0:16:33.20,Default,,0000,0000,0000,,Now, I said that there were 2 caveats.
Dialogue: 0,0:16:33.20,0:16:39.33,Default,,0000,0000,0000,,The second caveat is that\N0-RTT data can be replayed.
Dialogue: 0,0:16:39.33,0:16:45.45,Default,,0000,0000,0000,,The scenario is this: you have\Nsome data in the early data
Dialogue: 0,0:16:45.45,0:16:51.71,Default,,0000,0000,0000,,that is somehow authenticated. It might be\Na HTTP request with some cookies on it.
Dialogue: 0,0:16:51.71,0:16:58.07,Default,,0000,0000,0000,,And that HTTP request is somehow\Nexecuting a transaction,
Dialogue: 0,0:16:58.07,0:17:03.15,Default,,0000,0000,0000,,okay? Moving some money, instructing\Nthe server to do something. An attacker
Dialogue: 0,0:17:03.15,0:17:07.58,Default,,0000,0000,0000,,wants to make that happen multiple\Ntimes. It can’t decrypt it, of course
Dialogue: 0,0:17:07.58,0:17:13.15,Default,,0000,0000,0000,,– it’s protected with TLS. So it\Ncan’t read the cookie, and it can’t
Dialogue: 0,0:17:13.15,0:17:17.69,Default,,0000,0000,0000,,modify it because, of course, it’s\Nprotected with TLS. But it can record
Dialogue: 0,0:17:17.69,0:17:23.07,Default,,0000,0000,0000,,the encrypted message\Nand it can then replay it
Dialogue: 0,0:17:23.07,0:17:27.90,Default,,0000,0000,0000,,against the server. Now if you have\Na single server this is easy to fix.
Dialogue: 0,0:17:27.90,0:17:32.52,Default,,0000,0000,0000,,You just take a note of the messages you\Nhave seen before and you just say like
Dialogue: 0,0:17:32.52,0:17:37.50,Default,,0000,0000,0000,,“No, this looks exactly like something I\Ngot before”. But if, for example like
Dialogue: 0,0:17:37.50,0:17:42.27,Default,,0000,0000,0000,,Cloudflare you are running multiple data\Ncentres around the world, you cannot keep
Dialogue: 0,0:17:42.27,0:17:47.65,Default,,0000,0000,0000,,consistent state all the time, in real\Ntime across all machines. So there would
Dialogue: 0,0:17:47.65,0:17:52.37,Default,,0000,0000,0000,,be different machines that if they\Nreceive this message will go like
Dialogue: 0,0:17:52.37,0:17:57.53,Default,,0000,0000,0000,,“Sure I have the session ticket key,\NI decrypt the PSK, I use the PSK,
Dialogue: 0,0:17:57.53,0:18:02.08,Default,,0000,0000,0000,,I decrypt the early data, I find\Ninside something, I execute what
Dialogue: 0,0:18:02.08,0:18:07.51,Default,,0000,0000,0000,,it tells me to do.” Now, of\Ncourse, this is not desirable.
Dialogue: 0,0:18:07.51,0:18:13.01,Default,,0000,0000,0000,,One countermeasure that TLS offers\Nis that the client sends a value
Dialogue: 0,0:18:13.01,0:18:18.69,Default,,0000,0000,0000,,in that bundle which is how long\Nago in milliseconds I obtained
Dialogue: 0,0:18:18.69,0:18:23.79,Default,,0000,0000,0000,,the session ticket. The server\Nlooks at that value and
Dialogue: 0,0:18:23.79,0:18:29.08,Default,,0000,0000,0000,,if it does not match its own view of this\Ninformation it will reject the message.
Dialogue: 0,0:18:29.08,0:18:34.02,Default,,0000,0000,0000,,That means that if the attacker records\Nthe message and then 10 seconds later
Dialogue: 0,0:18:34.02,0:18:40.00,Default,,0000,0000,0000,,tries to replay it the times won’t\Nmatch and the server can drop it.
Dialogue: 0,0:18:40.00,0:18:44.51,Default,,0000,0000,0000,,But this is not a full solution because\Nif the attacker is fast enough
Dialogue: 0,0:18:44.51,0:18:50.37,Default,,0000,0000,0000,,it can still replay messages.\NSo, everything the server can do
Dialogue: 0,0:18:50.37,0:18:55.97,Default,,0000,0000,0000,,is either accept the\N0-RTT data, or reject it.
Dialogue: 0,0:18:55.97,0:19:00.57,Default,,0000,0000,0000,,It can’t just take some part of it or\Ntake a peek and then decide because
Dialogue: 0,0:19:00.57,0:19:05.54,Default,,0000,0000,0000,,it’s the ‘Server Hello’ message that\Nsays whether it’s accepted or rejected.
Dialogue: 0,0:19:05.54,0:19:09.76,Default,,0000,0000,0000,,And the client will keep sending early\Ndata until it gets the ‘Server Hello’.
Dialogue: 0,0:19:09.76,0:19:15.96,Default,,0000,0000,0000,,There’s a race here. So the server has to\Ngo blind and decide “Am I taking 0-RTT data
Dialogue: 0,0:19:15.96,0:19:20.99,Default,,0000,0000,0000,,or am I just rejecting it all?” If it’s\Ntaking it, and then it finds out that it’s
Dialogue: 0,0:19:20.99,0:19:26.75,Default,,0000,0000,0000,,something that it can’t process because\N“Oh god, there is a HTTP POST in here
Dialogue: 0,0:19:26.75,0:19:32.47,Default,,0000,0000,0000,,that says to move some money, I can’t\Ndo this unless I know it’s not replayed.”
Dialogue: 0,0:19:32.47,0:19:37.06,Default,,0000,0000,0000,,So the server has to get some\Nconfirmation. The good news is that
Dialogue: 0,0:19:37.06,0:19:40.60,Default,,0000,0000,0000,,if the server waits for the ‘Finished’\Nmessage… The server sends
Dialogue: 0,0:19:40.60,0:19:45.28,Default,,0000,0000,0000,,the ‘Server Hello’, the ‘Finished’\Nand waits for the client’s one.
Dialogue: 0,0:19:45.28,0:19:51.05,Default,,0000,0000,0000,,When the client’s one gets there it means\Nthat also the early data was not replayed,
Dialogue: 0,0:19:51.05,0:19:54.95,Default,,0000,0000,0000,,because that ‘Finished’ message\Nties together the entire handshake
Dialogue: 0,0:19:54.95,0:19:59.77,Default,,0000,0000,0000,,together with some random value that\Nthe server sent. So it’s impossible
Dialogue: 0,0:19:59.77,0:20:04.38,Default,,0000,0000,0000,,that it was replayed. So, this is\Nwhat a server can do: it can accept
Dialogue: 0,0:20:04.38,0:20:08.78,Default,,0000,0000,0000,,the early data and if it’s something\Nthat is not idempotent, something
Dialogue: 0,0:20:08.78,0:20:14.61,Default,,0000,0000,0000,,that is dangerous, if it’s replayed it\Ncan just wait for the confirmation.
Dialogue: 0,0:20:14.61,0:20:18.85,Default,,0000,0000,0000,,But that means it has to buffer it, and\Nthere’s a risk for an attack here, where
Dialogue: 0,0:20:18.85,0:20:25.58,Default,,0000,0000,0000,,an attacker just sends a HTTP POST, with\Na giant body just to fill your memory.
Dialogue: 0,0:20:25.58,0:20:31.84,Default,,0000,0000,0000,,So what we realised is that we could help\Nwith this if we wrote on the session tickets
Dialogue: 0,0:20:31.84,0:20:37.24,Default,,0000,0000,0000,,what’s the maximum amount of\Nearly data that the client can send.
Dialogue: 0,0:20:37.24,0:20:41.50,Default,,0000,0000,0000,,If we see someone sending more than\Nthat, then it’s an attacker and we
Dialogue: 0,0:20:41.50,0:20:47.50,Default,,0000,0000,0000,,close the connection, drop the\Nbuffer, free up the memory.
Dialogue: 0,0:20:47.50,0:20:52.97,Default,,0000,0000,0000,,But. Anyway. However\Ncountermeasures we deploy,
Dialogue: 0,0:20:52.97,0:20:58.78,Default,,0000,0000,0000,,unless we can keep global state across the\Nservers, we have to inform the application
Dialogue: 0,0:20:58.78,0:21:03.43,Default,,0000,0000,0000,,that “this data might be replayed”.\NThe spec knows this.
Dialogue: 0,0:21:03.43,0:21:08.15,Default,,0000,0000,0000,,So the TLS 1.3 spec EXPLICITLY says
Dialogue: 0,0:21:08.15,0:21:14.42,Default,,0000,0000,0000,,protocols must NOT use\N0-RTT without a profile
Dialogue: 0,0:21:14.42,0:21:19.16,Default,,0000,0000,0000,,that defines its use. Which means\N“without knowing what they are doing”.
Dialogue: 0,0:21:19.16,0:21:24.42,Default,,0000,0000,0000,,This means that TLS stack\NAPI’s have to do 1 round trip
Dialogue: 0,0:21:24.42,0:21:30.36,Default,,0000,0000,0000,,by default, which is not affected by\Nreplays, and then allow the server
Dialogue: 0,0:21:30.36,0:21:35.57,Default,,0000,0000,0000,,to call some API’s to either reject\Nor wait for the confirmation,
Dialogue: 0,0:21:35.57,0:21:41.47,Default,,0000,0000,0000,,and to let the client decide what goes\Ninto this dangerous re-playable
Dialogue: 0,0:21:41.47,0:21:46.04,Default,,0000,0000,0000,,piece of data. So this will change
Dialogue: 0,0:21:46.04,0:21:49.84,Default,,0000,0000,0000,,based on the protocols but what about\Nour favourite protocol? What about
Dialogue: 0,0:21:49.84,0:21:55.33,Default,,0000,0000,0000,,HTTP? Now HTTP should\Nbe easy, the HTTP spec,
Dialogue: 0,0:21:55.33,0:22:00.76,Default,,0000,0000,0000,,you go read it and it says “Well,\NGET requests are idempotent,
Dialogue: 0,0:22:00.76,0:22:06.15,Default,,0000,0000,0000,,they must not change anything on the\Nserver”. Solved! We will just allow
Dialogue: 0,0:22:06.15,0:22:10.67,Default,,0000,0000,0000,,GET requests in early data because even\Nif they are replayed nothing happened!
Dialogue: 0,0:22:10.67,0:22:16.64,Default,,0000,0000,0000,,Yay! Nope. {\i1}sighs{\i0} You will definitely\Nfind some server on the internet
Dialogue: 0,0:22:16.64,0:22:23.02,Default,,0000,0000,0000,,that has something like\N“send-money.php?to=filippo&amount=this”
Dialogue: 0,0:22:23.02,0:22:28.87,Default,,0000,0000,0000,,and it’s a GET request. And if an attacker\Nrecords this, which is early data,
Dialogue: 0,0:22:28.87,0:22:33.51,Default,,0000,0000,0000,,and then replays this against a different\Nserver in the pool, that will get executed
Dialogue: 0,0:22:33.51,0:22:38.78,Default,,0000,0000,0000,,twice. And we can’t have that.
Dialogue: 0,0:22:38.78,0:22:43.30,Default,,0000,0000,0000,,Now, so what can we do here?
Dialogue: 0,0:22:43.30,0:22:46.89,Default,,0000,0000,0000,,We make trade-offs!
Dialogue: 0,0:22:46.89,0:22:51.78,Default,,0000,0000,0000,,If you know your application, you can\Nmake very specific trade-offs. E.g.
Dialogue: 0,0:22:51.78,0:22:57.02,Default,,0000,0000,0000,,Google has been running QUIC\Nwith 0-RTT for the longest time,
Dialogue: 0,0:22:57.02,0:23:02.20,Default,,0000,0000,0000,,for 3 years I think? And that means that\Nthey know very well their application.
Dialogue: 0,0:23:02.20,0:23:07.42,Default,,0000,0000,0000,,And they know that they don’t have\Nany “send-money.php” endpoints.
Dialogue: 0,0:23:07.42,0:23:12.71,Default,,0000,0000,0000,,But if you are like Cloudflare that\Nfronts a wide number of applications
Dialogue: 0,0:23:12.71,0:23:17.72,Default,,0000,0000,0000,,you can’t make such wide sweeping\Nassumptions, and you have instead
Dialogue: 0,0:23:17.72,0:23:22.57,Default,,0000,0000,0000,,to hope for some middle ground. For\Nexample, something we might decide to do
Dialogue: 0,0:23:22.57,0:23:28.73,Default,,0000,0000,0000,,is to only allow GETs\Nto the root. So “GET /”
Dialogue: 0,0:23:28.73,0:23:33.20,Default,,0000,0000,0000,,which might be the most benefit because\Nmaybe most connections start like that,
Dialogue: 0,0:23:33.20,0:23:38.71,Default,,0000,0000,0000,,and the least likely to cause trouble.
Dialogue: 0,0:23:38.71,0:23:43.14,Default,,0000,0000,0000,,We are still working on how exactly to\Nbring this to applications. So if you know
Dialogue: 0,0:23:43.14,0:23:48.20,Default,,0000,0000,0000,,of an application that would get hurt\Nby something as simple as that
Dialogue: 0,0:23:48.20,0:23:53.84,Default,,0000,0000,0000,,do email us, but actually,\Nif you have an application
Dialogue: 0,0:23:53.84,0:23:59.16,Default,,0000,0000,0000,,that is that vulnerable I have\Nbad news. Thai Duong et. al.
Dialogue: 0,0:23:59.16,0:24:04.15,Default,,0000,0000,0000,,demonstrated that browsers will\Ntoday, without TLS 1.3 or anything,
Dialogue: 0,0:24:04.15,0:24:09.74,Default,,0000,0000,0000,,replay HTTP requests\Nif network errors happen.
Dialogue: 0,0:24:09.74,0:24:15.67,Default,,0000,0000,0000,,And they will replay them silently.\NSo it might not be actually worse
Dialogue: 0,0:24:15.67,0:24:21.99,Default,,0000,0000,0000,,than the current state. Okay.\NI can actually see everyone
Dialogue: 0,0:24:21.99,0:24:27.96,Default,,0000,0000,0000,,getting uneasy in their seats, thinking\N“There the cryptographers are at it again!
Dialogue: 0,0:24:27.96,0:24:32.74,Default,,0000,0000,0000,,They are making the security protocol that\Nwe need more complex than it has to be
Dialogue: 0,0:24:32.74,0:24:38.89,Default,,0000,0000,0000,,to get their job security for\Nthe next 15 years!” Right?
Dialogue: 0,0:24:38.89,0:24:44.48,Default,,0000,0000,0000,,No. No. I can actually assure you that
Dialogue: 0,0:24:44.48,0:24:49.71,Default,,0000,0000,0000,,one of the big changes, in my opinion\Neven bigger than the round trips in 1.3,
Dialogue: 0,0:24:49.71,0:24:54.77,Default,,0000,0000,0000,,is that everything is being weighted\Nfor the benefit against the complexity
Dialogue: 0,0:24:54.77,0:24:59.18,Default,,0000,0000,0000,,that it introduces. And\Nwhile 0-RTT made the cut
Dialogue: 0,0:24:59.18,0:25:02.63,Default,,0000,0000,0000,,most other things definitely didn’t.
Dialogue: 0,0:25:02.63,0:25:07.89,Default,,0000,0000,0000,,Nick: Right. Thanks Filippo.
Dialogue: 0,0:25:07.89,0:25:13.64,Default,,0000,0000,0000,,In TLS 1.3 as an iteration of\NTLS we also went back, or,
Dialogue: 0,0:25:13.64,0:25:18.12,Default,,0000,0000,0000,,“we” being the people who are\Nlooking at TLS, went back and
Dialogue: 0,0:25:18.12,0:25:22.77,Default,,0000,0000,0000,,revisited the existing TLS 1.2 features\Nthat sort of seemed reasonable at the time
Dialogue: 0,0:25:22.77,0:25:27.44,Default,,0000,0000,0000,,and decided whether or not the complexity\Nand the danger added by these features,
Dialogue: 0,0:25:27.44,0:25:32.35,Default,,0000,0000,0000,,or these protocols, or these\Nprimitives involved in TLS were
Dialogue: 0,0:25:32.35,0:25:37.74,Default,,0000,0000,0000,,reasonable to keep. And the big one which\Nhappened early on in the process is
Dialogue: 0,0:25:37.74,0:25:43.79,Default,,0000,0000,0000,,‘Static RSA’ mode. So this is the way that\NTLS has been working back since SSL.
Dialogue: 0,0:25:43.79,0:25:48.18,Default,,0000,0000,0000,,Rather than using Diffie-Hellman to\Nestablish a shared key… How this works is,
Dialogue: 0,0:25:48.18,0:25:52.32,Default,,0000,0000,0000,,the client will make its own shared\Nkey, and encrypt it with the server’s
Dialogue: 0,0:25:52.32,0:25:56.57,Default,,0000,0000,0000,,certificate public key which is gonna\Nbe an RSA key, and then just send it
Dialogue: 0,0:25:56.57,0:26:00.77,Default,,0000,0000,0000,,in plain text over the wire to the server.\NAnd then the server would use its
Dialogue: 0,0:26:00.77,0:26:04.65,Default,,0000,0000,0000,,private key to decrypt that, and then\Nestablish a shared key. So the client
Dialogue: 0,0:26:04.65,0:26:09.71,Default,,0000,0000,0000,,creates all the key material in this case.\NAnd one thing that is sort of obvious
Dialogue: 0,0:26:09.71,0:26:13.65,Default,,0000,0000,0000,,from this is that if the private key\Nfor the certificate is comprised,
Dialogue: 0,0:26:13.65,0:26:18.15,Default,,0000,0000,0000,,even after the fact, even years later,\Nsomeone with the transcript of what happened
Dialogue: 0,0:26:18.15,0:26:23.48,Default,,0000,0000,0000,,can go back and decrypt this key material,\Nand then see the entire conversation.
Dialogue: 0,0:26:23.48,0:26:28.42,Default,,0000,0000,0000,,So this was removed very early in the\Nprocess, somewhere around 2 years ago
Dialogue: 0,0:26:28.42,0:26:33.92,Default,,0000,0000,0000,,in TLS 1.3. So, much to our surprise,\Nand the surprise of everyone
Dialogue: 0,0:26:33.92,0:26:39.68,Default,,0000,0000,0000,,reading the TLS mailing\Nlist, just very recently,
Dialogue: 0,0:26:39.68,0:26:44.61,Default,,0000,0000,0000,,near the end of the standardisation\Nprocess where TLS 1.3 was almost final
Dialogue: 0,0:26:44.61,0:26:50.80,Default,,0000,0000,0000,,this e-mail landed on the list. And this\Nis from Andrew Kennedy who works at BITS
Dialogue: 0,0:26:50.80,0:26:56.55,Default,,0000,0000,0000,,which basically means he works\Nat banks. So this is what he said:
Dialogue: 0,0:26:56.55,0:27:01.67,Default,,0000,0000,0000,,“Deprecation of the RSA key exchange\Nin TLS 1.3 will cause significant problems
Dialogue: 0,0:27:01.67,0:27:06.76,Default,,0000,0000,0000,,for financial institutions, almost all of\Nwhom are running TLS internally and have
Dialogue: 0,0:27:06.76,0:27:12.51,Default,,0000,0000,0000,,significant, security-critical investments\Nin out-of-band TLS decryption”.
Dialogue: 0,0:27:12.51,0:27:17.81,Default,,0000,0000,0000,,“Out-of-band TLS decryption”… mmh…\N{\i1}laughs{\i0} - {\i1}applause{\i0}
Dialogue: 0,0:27:17.81,0:27:23.49,Default,,0000,0000,0000,,That certainly sounds critical…\Ncritical for someone, right?
Dialogue: 0,0:27:23.49,0:27:26.14,Default,,0000,0000,0000,,{\i1}laughs{\i0} - {\i1}applause{\i0}\NSo…
Dialogue: 0,0:27:26.14,0:27:32.20,Default,,0000,0000,0000,,{\i1}laughs{\i0}\N{\i1}applause{\i0}
Dialogue: 0,0:27:32.20,0:27:37.04,Default,,0000,0000,0000,,So one of the bright spots was\NKenny Paterson’s response to this,
Dialogue: 0,0:27:37.04,0:27:41.68,Default,,0000,0000,0000,,in which he said: “My view\Nconcerning your request: no.
Dialogue: 0,0:27:41.68,0:27:44.92,Default,,0000,0000,0000,,Rationale: We’re trying to build a MORE\Nsecure internet.” The emphasis on ‘more’
Dialogue: 0,0:27:44.92,0:27:47.35,Default,,0000,0000,0000,,is mine but I’m sure he meant it, yeah.
Dialogue: 0,0:27:47.35,0:27:54.10,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:27:54.10,0:27:58.84,Default,,0000,0000,0000,,So after this the banking folks came\Nto the IETF and presented this slide
Dialogue: 0,0:27:58.84,0:28:04.46,Default,,0000,0000,0000,,to describe how hard it was to actually\Ndebug their system. This is a very simple…
Dialogue: 0,0:28:04.46,0:28:09.27,Default,,0000,0000,0000,,I guess, with respect to banking. Those\Nare the different switches, routers,
Dialogue: 0,0:28:09.27,0:28:14.48,Default,,0000,0000,0000,,middle ware, web applications; and\Neverything talks TLS one to the other.
Dialogue: 0,0:28:14.48,0:28:19.73,Default,,0000,0000,0000,,And after this discussion we decided\Nwe came to a compromise.
Dialogue: 0,0:28:19.73,0:28:24.16,Default,,0000,0000,0000,,But instead of actually compromising\Nthe protocol Matthew Green
Dialogue: 0,0:28:24.16,0:28:28.90,Default,,0000,0000,0000,,taught them how to use Diffie-Hellman\Nincorrectly. They ended up actually
Dialogue: 0,0:28:28.90,0:28:33.11,Default,,0000,0000,0000,,being able to do what they wanted\Nto do, without us – or anybody
Dialogue: 0,0:28:33.11,0:28:36.78,Default,,0000,0000,0000,,in the academic community, or in the\NTLS community – adding back this
Dialogue: 0,0:28:36.78,0:28:41.72,Default,,0000,0000,0000,,insecure piece of TLS.
Dialogue: 0,0:28:41.72,0:28:45.58,Default,,0000,0000,0000,,So if you want to read this it shows\Nhow to do it. But in any case
Dialogue: 0,0:28:45.58,0:28:49.97,Default,,0000,0000,0000,,– we didn’t add it back.\NDon’t do this, basically! {\i1}laughs{\i0}
Dialogue: 0,0:28:49.97,0:28:54.30,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:28:54.30,0:29:00.10,Default,,0000,0000,0000,,So we killed static RSA, and\Nwhat else did we kill? Well,
Dialogue: 0,0:29:00.10,0:29:03.77,Default,,0000,0000,0000,,looking back on the trade-offs there is\Na number of primitives that are in use
Dialogue: 0,0:29:03.77,0:29:08.52,Default,,0000,0000,0000,,in TLS 1.2 and earlier that just\Nhaven’t stood the test of time.
Dialogue: 0,0:29:08.52,0:29:12.13,Default,,0000,0000,0000,,So, RC4 stream cipher. Gone!\N{\i1}applause{\i0}
Dialogue: 0,0:29:12.13,0:29:14.79,Default,,0000,0000,0000,,3DES (Triple DES) block cipher. Gone!\N{\i1}applause{\i0}
Dialogue: 0,0:29:14.79,0:29:21.53,Default,,0000,0000,0000,,MD5, SHA1… all gone. Yo!\N{\i1}ongoing applause{\i0}
Dialogue: 0,0:29:21.53,0:29:26.48,Default,,0000,0000,0000,,There is even constructions that took…\Nbasic block cipher constructions
Dialogue: 0,0:29:26.48,0:29:31.64,Default,,0000,0000,0000,,that are gone: AES-CBC.\NGone. RSA-PKCS1-1.5,
Dialogue: 0,0:29:31.64,0:29:36.81,Default,,0000,0000,0000,,this has been known to have been\Nproblematic since 1998, also gone!
Dialogue: 0,0:29:36.81,0:29:41.77,Default,,0000,0000,0000,,They have also removed several features\Nlike Compression and Renegotiation which
Dialogue: 0,0:29:41.77,0:29:47.13,Default,,0000,0000,0000,,was replaced with a very lightweight\N‘key update’ mechanism. So in TLS 1.3
Dialogue: 0,0:29:47.13,0:29:52.49,Default,,0000,0000,0000,,none of these met the balance of\Nbenefit vs. complexity. And a lot of these
Dialogue: 0,0:29:52.49,0:29:58.03,Default,,0000,0000,0000,,vulnerabilities, you might recognize, are\Njust impossible in TLS 1.3. So that’s good.
Dialogue: 0,0:29:58.03,0:30:04.01,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:30:04.01,0:30:09.15,Default,,0000,0000,0000,,So the philosophy for TLS 1.3 in a lot of\Nplaces is simplify and make it more robust
Dialogue: 0,0:30:09.15,0:30:14.55,Default,,0000,0000,0000,,as much as possible. There are a number\Nof little cases in which we did that.
Dialogue: 0,0:30:14.55,0:30:18.68,Default,,0000,0000,0000,,Some of the authors of this paper may be\Nin the audience right now. But there is
Dialogue: 0,0:30:18.68,0:30:24.03,Default,,0000,0000,0000,,a way in which block ciphers where\Nused for the actual record layer
Dialogue: 0,0:30:24.03,0:30:27.64,Default,,0000,0000,0000,,that was not as robust as it could be.\NIt has been replaced with a much simpler
Dialogue: 0,0:30:27.64,0:30:32.34,Default,,0000,0000,0000,,mechanism. TLS 1.2 had this
Dialogue: 0,0:30:32.34,0:30:37.52,Default,,0000,0000,0000,,really kind of funny ‘Catch 22’ in it\Nwhere the cipher negotiation
Dialogue: 0,0:30:37.52,0:30:41.81,Default,,0000,0000,0000,,is protected by a ‘Finished’ message which\Nis a message-authentication code, but
Dialogue: 0,0:30:41.81,0:30:47.02,Default,,0000,0000,0000,,the algorithm for that code was determined\Nin the cipher negotiation, so,
Dialogue: 0,0:30:47.02,0:30:53.09,Default,,0000,0000,0000,,it had this kind of loop-back effect. And\Nattacks like FREAK, LogJam and CurveSwap
Dialogue: 0,0:30:53.09,0:30:59.30,Default,,0000,0000,0000,,(from last year) managed to exploit these\Nto actually downgrade connections.
Dialogue: 0,0:30:59.30,0:31:02.67,Default,,0000,0000,0000,,And this was something that was happening\Nin the wild. And the reason for this is
Dialogue: 0,0:31:02.67,0:31:06.98,Default,,0000,0000,0000,,that these cipher suites in this handshake\Nare not actually digitally signed
Dialogue: 0,0:31:06.98,0:31:11.65,Default,,0000,0000,0000,,by the private key. And in TLS 1.3\Nthis was changed. Everything
Dialogue: 0,0:31:11.65,0:31:16.13,Default,,0000,0000,0000,,from the signature up is digitally\Nsigned. So this is great!
Dialogue: 0,0:31:16.13,0:31:21.29,Default,,0000,0000,0000,,What else did we change? Well,\Nwhat else did TLS 1.3 change
Dialogue: 0,0:31:21.29,0:31:27.86,Default,,0000,0000,0000,,vs. TLS 1.2? And that is: fewer, better\Nchoices. And in cryptography
Dialogue: 0,0:31:27.86,0:31:33.41,Default,,0000,0000,0000,,better choices always means fewer choices.\NSo there is now a shortlist of curves and
Dialogue: 0,0:31:33.41,0:31:36.92,Default,,0000,0000,0000,,finite field groups that you can use. And\Nno arbitrary Diffie-Hellman groups made up
Dialogue: 0,0:31:36.92,0:31:41.95,Default,,0000,0000,0000,,by the server, no arbitrary curves\Nthat can be used. And this sort of
Dialogue: 0,0:31:41.95,0:31:47.94,Default,,0000,0000,0000,,shortening of the list of parameters\Nreally enables 1-RTT to work
Dialogue: 0,0:31:47.94,0:31:51.96,Default,,0000,0000,0000,,a lot of the time. So as Filippo\Nmentioned, the client has to guess
Dialogue: 0,0:31:51.96,0:31:56.54,Default,,0000,0000,0000,,which key establishment\Nmethods the server supports,
Dialogue: 0,0:31:56.54,0:32:01.20,Default,,0000,0000,0000,,and send that key share. If there is\Na short list of only-secure options
Dialogue: 0,0:32:01.20,0:32:05.60,Default,,0000,0000,0000,,this happens a larger percentage of\Nthe time. So when you’re configuring
Dialogue: 0,0:32:05.60,0:32:10.76,Default,,0000,0000,0000,,your TLS server it no longer looks\Nlike a complicated takeout menu,
Dialogue: 0,0:32:10.76,0:32:15.69,Default,,0000,0000,0000,,it’s more like a wedding [menu]. Take one\Nof each, and it’s a lot more delicious
Dialogue: 0,0:32:15.69,0:32:21.97,Default,,0000,0000,0000,,anyways. And you can look on\NWireshark, it’s also very simple.
Dialogue: 0,0:32:21.97,0:32:27.80,Default,,0000,0000,0000,,The cipher suites use extensions,\Nthe curves, and you can go from there.
Dialogue: 0,0:32:27.80,0:32:33.30,Default,,0000,0000,0000,,Filippo: Now, TLS 1.3 also fixed\Nwhat I think was one of the biggest
Dialogue: 0,0:32:33.30,0:32:37.44,Default,,0000,0000,0000,,actual design mistakes of\NTLS 1.2. We talked about
Dialogue: 0,0:32:37.44,0:32:43.41,Default,,0000,0000,0000,,how forward secrecy works\Nwith resumption in 1.2 and 1.3.
Dialogue: 0,0:32:43.41,0:32:49.20,Default,,0000,0000,0000,,But TLS 1.2 is even more\Nproblematic. TLS 1.2 wraps
Dialogue: 0,0:32:49.20,0:32:55.68,Default,,0000,0000,0000,,inside the session tickets the actual\Nmaster secret of the old connection.
Dialogue: 0,0:32:55.68,0:33:02.51,Default,,0000,0000,0000,,So it takes the actual keys that encrypt\Nthe traffic of the original connection,
Dialogue: 0,0:33:02.51,0:33:07.86,Default,,0000,0000,0000,,encrypts them with the session ticket key,\Nand sends that to the client to be sent
Dialogue: 0,0:33:07.86,0:33:13.62,Default,,0000,0000,0000,,back the next time. We talked about\Nhow there’s a risk that an attacker will
Dialogue: 0,0:33:13.62,0:33:18.14,Default,,0000,0000,0000,,obtain session ticket keys, and decrypt\Nthe session tickets, and break
Dialogue: 0,0:33:18.14,0:33:23.86,Default,,0000,0000,0000,,the forward secrecy and decrypt\Nthe resumed connections. Well,
Dialogue: 0,0:33:23.86,0:33:29.78,Default,,0000,0000,0000,,in TLS 1.2 it’s even worse. If they\Ndecrypt the session tickets they could
Dialogue: 0,0:33:29.78,0:33:35.95,Default,,0000,0000,0000,,go back and backward decrypt the original
Dialogue: 0,0:33:35.95,0:33:42.09,Default,,0000,0000,0000,,non-resumed connection. And\Nthis is completely unnecessary.
Dialogue: 0,0:33:42.09,0:33:46.77,Default,,0000,0000,0000,,We have hash functions, we have one-way\Nfunctions where you put an input in
Dialogue: 0,0:33:46.77,0:33:52.99,Default,,0000,0000,0000,,and you get something that you can’t\Ngo back from. So that’s what 1.3 does.
Dialogue: 0,0:33:52.99,0:33:58.58,Default,,0000,0000,0000,,1.3 derives new keys, fresh\Nkeys for the next connection
Dialogue: 0,0:33:58.58,0:34:04.09,Default,,0000,0000,0000,,and wraps them inside the session ticket\Nto become the PSK. So even if you
Dialogue: 0,0:34:04.09,0:34:09.44,Default,,0000,0000,0000,,decrypt a 1.3 session ticket\Nyou can then attack
Dialogue: 0,0:34:09.44,0:34:13.62,Default,,0000,0000,0000,,the subsequent connection, and we’ve\Nseen that you might be able to decrypt
Dialogue: 0,0:34:13.62,0:34:18.95,Default,,0000,0000,0000,,only the early data, or all the connection\Ndepending on what mode it uses. But
Dialogue: 0,0:34:18.95,0:34:25.96,Default,,0000,0000,0000,,you definitely can’t decrypt the\Noriginal non-resumed connection.
Dialogue: 0,0:34:25.96,0:34:31.73,Default,,0000,0000,0000,,So, this would be bad enough, but 1.2\Nmakes another decision that entirely
Dialogue: 0,0:34:31.73,0:34:36.76,Default,,0000,0000,0000,,puzzled me. The whole ‘using the master\Nsecret’ might be just because session
Dialogue: 0,0:34:36.76,0:34:41.78,Default,,0000,0000,0000,,tickets were an extension in\N1.2, which they are not in 1.3.
Dialogue: 0,0:34:41.78,0:34:47.99,Default,,0000,0000,0000,,But, 1.2 sends the new session\Nticket message at the beginning
Dialogue: 0,0:34:47.99,0:34:53.49,Default,,0000,0000,0000,,of the original handshake,\Nunencrypted! I mean
Dialogue: 0,0:34:53.49,0:34:58.67,Default,,0000,0000,0000,,encrypted with the session ticket keys\Nbut not with the current session keys.
Dialogue: 0,0:34:58.67,0:35:04.04,Default,,0000,0000,0000,,So, any server that just supports
Dialogue: 0,0:35:04.04,0:35:10.13,Default,,0000,0000,0000,,session tickets will have at the\Nbeginning of all connections,
Dialogue: 0,0:35:10.13,0:35:14.67,Default,,0000,0000,0000,,even if resumption never happens, they\Nwill have a session ticket which is
Dialogue: 0,0:35:14.67,0:35:18.82,Default,,0000,0000,0000,,nothing else than the ephemeral\Nkeys of that connection
Dialogue: 0,0:35:18.82,0:35:23.40,Default,,0000,0000,0000,,wrapped with the session\Nticket keys. Now, if you are
Dialogue: 0,0:35:23.40,0:35:28.62,Default,,0000,0000,0000,,a global passive adversary\Nthat somehow wants to do
Dialogue: 0,0:35:28.62,0:35:33.06,Default,,0000,0000,0000,,passive dragnet surveillance and\Nyou wanted to passively decrypt
Dialogue: 0,0:35:33.06,0:35:38.72,Default,,0000,0000,0000,,all the connections, and somehow you\Nwere able to obtain session ticket keys,
Dialogue: 0,0:35:38.72,0:35:44.35,Default,,0000,0000,0000,,what you would find at the beginning\Nof every TLS 1.2 connection is
Dialogue: 0,0:35:44.35,0:35:49.83,Default,,0000,0000,0000,,the session keys encrypted with\Nthe session ticket keys. Now,
Dialogue: 0,0:35:49.83,0:35:55.58,Default,,0000,0000,0000,,1.3 solves this, and in 1.3 this kind\Nof attacks are completely impossible.
Dialogue: 0,0:35:55.58,0:35:59.42,Default,,0000,0000,0000,,The only thing that you can passively\Ndecrypt, or decrypt after the fact,
Dialogue: 0,0:35:59.42,0:36:04.23,Default,,0000,0000,0000,,is the early data, and definitely not non-\Nresumed connections, and definitely not
Dialogue: 0,0:36:04.23,0:36:10.92,Default,,0000,0000,0000,,anything that comes after 0-RTT.
Dialogue: 0,0:36:10.92,0:36:12.84,Default,,0000,0000,0000,,Nick: So it’s safer, basically.\N{\i1}laughs{\i0}
Dialogue: 0,0:36:12.84,0:36:15.71,Default,,0000,0000,0000,,Filippo: Hope so!\NNick: …hopefully.
Dialogue: 0,0:36:15.71,0:36:20.67,Default,,0000,0000,0000,,And how do we know that it’s safer? Well,\Nthese security parameters, and these
Dialogue: 0,0:36:20.67,0:36:25.84,Default,,0000,0000,0000,,security requirements of TLS have been\Nformalized and, as opposed to earlier
Dialogue: 0,0:36:25.84,0:36:30.31,Default,,0000,0000,0000,,versions of TLS the folks in the academic\Ncommunity who do formal verification were
Dialogue: 0,0:36:30.31,0:36:34.17,Default,,0000,0000,0000,,involved earlier. So there have been\Nseveral papers analyzing the state machine
Dialogue: 0,0:36:34.17,0:36:40.12,Default,,0000,0000,0000,,and analyzing the different modes of\NTLS 1.3, and these have aided a lot
Dialogue: 0,0:36:40.12,0:36:45.36,Default,,0000,0000,0000,,in the development\Nof the protocol. So,
Dialogue: 0,0:36:45.36,0:36:50.57,Default,,0000,0000,0000,,who actually develops TLS 1.3? Well, it’s
Dialogue: 0,0:36:50.57,0:36:54.73,Default,,0000,0000,0000,,an organization called the IETF which is\Nthe Internet Engineering Taskforce. It’s
Dialogue: 0,0:36:54.73,0:36:59.76,Default,,0000,0000,0000,,a group of volunteers that meet 3 times\Na year and have mailing lists, and they
Dialogue: 0,0:36:59.76,0:37:03.46,Default,,0000,0000,0000,,debate these protocols endlessly. They\Ndefine the protocols that are used
Dialogue: 0,0:37:03.46,0:37:07.91,Default,,0000,0000,0000,,on the internet. And originally, the first\Nthing that I ever saw about this – this is
Dialogue: 0,0:37:07.91,0:37:13.25,Default,,0000,0000,0000,,a tweet of mine from September\N2013 – was a wish list for TLS 1.3.
Dialogue: 0,0:37:13.25,0:37:19.92,Default,,0000,0000,0000,,And since then they came out\Nwith a first draft at the IETF…
Dialogue: 0,0:37:19.92,0:37:24.63,Default,,0000,0000,0000,,Documents that define protocols\Nare known as RFCs, and
Dialogue: 0,0:37:24.63,0:37:29.20,Default,,0000,0000,0000,,the lead-up to something becoming an RFC\Nis an ‘Internet Draft’. So you start with
Dialogue: 0,0:37:29.20,0:37:34.33,Default,,0000,0000,0000,,the Internet Draft 0, and then you iterate\Non this draft until finally it gets
Dialogue: 0,0:37:34.33,0:37:39.98,Default,,0000,0000,0000,,accepted or rejected as an RFC. So\Nthe first one was almost 3 years ago
Dialogue: 0,0:37:39.98,0:37:46.08,Default,,0000,0000,0000,,back in April 2014, and the current\Ndraft (18) which is considered to be
Dialogue: 0,0:37:46.08,0:37:51.59,Default,,0000,0000,0000,,almost final, it’s in what is\Ncalled ‘Last Call’ at the IETF,
Dialogue: 0,0:37:51.59,0:37:57.33,Default,,0000,0000,0000,,was just recently in October.\NIn the security landscape
Dialogue: 0,0:37:57.33,0:38:02.40,Default,,0000,0000,0000,,during that time you’ve seen so many\Ndifferent types of attacks on TLS. So:
Dialogue: 0,0:38:02.40,0:38:07.86,Default,,0000,0000,0000,,Triple Handshake, POODLE, FREAK, Logjam,\NDROWN (there was a talk about that earlier
Dialogue: 0,0:38:07.86,0:38:12.22,Default,,0000,0000,0000,,today), Lucky Microseconds, SLOTH.\NAll these different types of acronyms
Dialogue: 0,0:38:12.22,0:38:15.55,Default,,0000,0000,0000,,– you may or may not have heard of –\Nhave happened during the development.
Dialogue: 0,0:38:15.55,0:38:21.38,Default,,0000,0000,0000,,So TLS 1.3 is a living\Ndocument, and it’s hopefully
Dialogue: 0,0:38:21.38,0:38:27.56,Default,,0000,0000,0000,,going to be small. I mean,\NTLS 1.2 was 79 pages.
Dialogue: 0,0:38:27.56,0:38:32.52,Default,,0000,0000,0000,,It’s kind of a rough read, but\Ngive it a shot! If you like. TLS 1.3
Dialogue: 0,0:38:32.52,0:38:36.33,Default,,0000,0000,0000,,if you shave off a lot of the excess stuff\Nat the end is actually close. And it’s
Dialogue: 0,0:38:36.33,0:38:40.98,Default,,0000,0000,0000,,a lot nicer read, it’s a lot more precise,\Neven though there are some interesting
Dialogue: 0,0:38:40.98,0:38:46.91,Default,,0000,0000,0000,,features like 0-RTT, resumption. So\Npractically, how does it get written?
Dialogue: 0,0:38:46.91,0:38:52.81,Default,,0000,0000,0000,,Well it’s, uh… Github! And a mailing list!\NSo if you want to send a pull request
Dialogue: 0,0:38:52.81,0:38:59.02,Default,,0000,0000,0000,,to this TLS working group, there it is.\NThis is actually how the draft gets defined.
Dialogue: 0,0:38:59.02,0:39:04.19,Default,,0000,0000,0000,,And you probably want to send a message\Nto the mailing list to describe what your
Dialogue: 0,0:39:04.19,0:39:09.30,Default,,0000,0000,0000,,change is, if you want to. I suggest if\Nanybody wants to be involved this is
Dialogue: 0,0:39:09.30,0:39:14.19,Default,,0000,0000,0000,,pretty late. I mean it’s in ‘Last Call’…\NBut the mailing list is still open. Now
Dialogue: 0,0:39:14.19,0:39:18.37,Default,,0000,0000,0000,,I’ve been working on this with a bunch of\Nother people, Filippo as well. We were
Dialogue: 0,0:39:18.37,0:39:23.23,Default,,0000,0000,0000,,contributors on the draft, been working\Nfor over a year on this. You can check
Dialogue: 0,0:39:23.23,0:39:29.23,Default,,0000,0000,0000,,the Github issues to see how much work\Nhas gone into it. The draft has changed
Dialogue: 0,0:39:29.23,0:39:34.13,Default,,0000,0000,0000,,over the years and months.
Dialogue: 0,0:39:34.13,0:39:38.62,Default,,0000,0000,0000,,E.g. Draft 9 had this very\Ncomplicated tree structure
Dialogue: 0,0:39:38.62,0:39:43.55,Default,,0000,0000,0000,,for a key schedule, you can see\Nhtk… all these different things
Dialogue: 0,0:39:43.55,0:39:49.98,Default,,0000,0000,0000,,had to do with different keys in the TLS\Nhandshake. And this was inspired by QUIC,
Dialogue: 0,0:39:49.98,0:39:55.65,Default,,0000,0000,0000,,the Google protocol that Filippo mentioned\Nearlier as well as a paper called ‘OPTLS’.
Dialogue: 0,0:39:55.65,0:40:00.61,Default,,0000,0000,0000,,And it had lots of different modes,\Nsemi-static Diffie-Hellman, and this
Dialogue: 0,0:40:00.61,0:40:04.95,Default,,0000,0000,0000,,tree-based key schedule. And over the\Ntime this was widdled down from this
Dialogue: 0,0:40:04.95,0:40:10.51,Default,,0000,0000,0000,,complicated diagram to what we have\Nnow in TLS 1.3. Which is a very simple
Dialogue: 0,0:40:10.51,0:40:16.33,Default,,0000,0000,0000,,derivation algorithm. This took a lot\Nof work to get from something big
Dialogue: 0,0:40:16.33,0:40:21.67,Default,,0000,0000,0000,,to something small. But it’s happened!\NOther things that happened
Dialogue: 0,0:40:21.67,0:40:27.23,Default,,0000,0000,0000,,in TLS 1.3 are sort of less substantial,\Ncryptographically, and that involves
Dialogue: 0,0:40:27.23,0:40:32.55,Default,,0000,0000,0000,,naming! If anyone has been following\Nalong, TLS 1.3 is not necessarily
Dialogue: 0,0:40:32.55,0:40:38.18,Default,,0000,0000,0000,,the unanimous choice for the name of this\Nprotocol. It’s, as Filippo mentioned, 1.0,
Dialogue: 0,0:40:38.18,0:40:44.00,Default,,0000,0000,0000,,1.1, 1.2 are pretty small iterations\Neven on SSLv3, whereas
Dialogue: 0,0:40:44.00,0:40:49.07,Default,,0000,0000,0000,,TLS 1.3 is quite a big change.\NSo there is a lot of options
Dialogue: 0,0:40:49.07,0:40:54.95,Default,,0000,0000,0000,,for names! Let’s have\Na show of hands: Who here
Dialogue: 0,0:40:54.95,0:40:59.86,Default,,0000,0000,0000,,thinks it should be called 1.3?\N{\i1}laughs{\i0}
Dialogue: 0,0:40:59.86,0:41:02.03,Default,,0000,0000,0000,,Thanks, Filippo! {\i1}Filippo laughs{\i0}\NYeah, so, pretty good number.
Dialogue: 0,0:41:02.03,0:41:07.84,Default,,0000,0000,0000,,How about TLS 2? Anybody?\NWell, that actually looks like more than…
Dialogue: 0,0:41:07.84,0:41:12.94,Default,,0000,0000,0000,,Filippo: Remember that SSLv2 is\Na thing! And it’s a terrible thing!
Dialogue: 0,0:41:12.94,0:41:18.04,Default,,0000,0000,0000,,Nick: You don’t want to confuse\Nthat with us! So how about TLS 4?
Dialogue: 0,0:41:18.04,0:41:22.52,Default,,0000,0000,0000,,Still a significant number of people…\NHow about TLS 2017? Yeah…\N
Dialogue: 0,0:41:22.52,0:41:25.78,Default,,0000,0000,0000,,Alright! TLS 7 anybody? Okay…
Dialogue: 0,0:41:25.78,0:41:30.40,Default,,0000,0000,0000,,Filippo: TLS Millennium 2019 X?
Dialogue: 0,0:41:30.40,0:41:35.41,Default,,0000,0000,0000,,YES! Sold!\NNick: Alright! TLS Vista?
Dialogue: 0,0:41:35.41,0:41:38.86,Default,,0000,0000,0000,,{\i1}laughter{\i0} - {\i1}Nick and Filippo laugh{\i0}\N{\i1}applause{\i0}
Dialogue: 0,0:41:38.86,0:41:44.80,Default,,0000,0000,0000,,Nick: Lots of options! But just as\Na reminder, the rest of the world
Dialogue: 0,0:41:44.80,0:41:50.04,Default,,0000,0000,0000,,doesn’t really call it TLS. This is Google\Ntrends, interest over time, searching for
Dialogue: 0,0:41:50.04,0:41:55.30,Default,,0000,0000,0000,,‘SSL vs. TLS’. SSL is really what most\Nof the world calls this protocol. So SSL
Dialogue: 0,0:41:55.30,0:42:00.24,Default,,0000,0000,0000,,has the highest version of Version 3,\Nand that’s kind of the reason why people
Dialogue: 0,0:42:00.24,0:42:05.21,Default,,0000,0000,0000,,thought ‘TLS 4’ was a good idea, because\N“Oh, people are confused: 3 is higher
Dialogue: 0,0:42:05.21,0:42:10.72,Default,,0000,0000,0000,,than 1.2, yada-yada-yada”.
Dialogue: 0,0:42:10.72,0:42:14.87,Default,,0000,0000,0000,,This poll was not the only poll. It was\Ntaken there some informal twitter polls.
Dialogue: 0,0:42:14.87,0:42:20.03,Default,,0000,0000,0000,,“Mmm, Bacon!” was a good one,\N52% of Ryan Hurst’s poll.
Dialogue: 0,0:42:20.03,0:42:23.87,Default,,0000,0000,0000,,{\i1}laughter{\i0}
Dialogue: 0,0:42:23.87,0:42:28.13,Default,,0000,0000,0000,,Versions are a really sticky thing in TLS.
Dialogue: 0,0:42:28.13,0:42:32.78,Default,,0000,0000,0000,,E.g. the versions that we have of TLS\N– if you look at them on the wire
Dialogue: 0,0:42:32.78,0:42:37.64,Default,,0000,0000,0000,,they actually don’t match up.\NSo SSL 3 is 3.0 which does match up.
Dialogue: 0,0:42:37.64,0:42:43.72,Default,,0000,0000,0000,,But TLS 1 is 3.1; 3.2…\NTLS 1.2 is 3.3; and originally
Dialogue: 0,0:42:43.72,0:42:49.00,Default,,0000,0000,0000,,I think up to Draft 16\Nof TLS 1.3 it was 3.4.
Dialogue: 0,0:42:49.00,0:42:53.76,Default,,0000,0000,0000,,Just sort of a bumping the minor\Nversion of TLS 1.2, very confusing.
Dialogue: 0,0:42:53.76,0:42:58.51,Default,,0000,0000,0000,,But after doing some internet\Nmeasurement it was determined that
Dialogue: 0,0:42:58.51,0:43:02.67,Default,,0000,0000,0000,,a lot of servers, if you send a ‘Client\NHello’ with ‘3.4’, it just disconnects. So
Dialogue: 0,0:43:02.67,0:43:07.96,Default,,0000,0000,0000,,this is actually really bad, it prevents\Nbrowsers from being able to actually
Dialogue: 0,0:43:07.96,0:43:13.08,Default,,0000,0000,0000,,safely downgrade. What a server is\Nsupposed to do if it sees a version
Dialogue: 0,0:43:13.08,0:43:18.78,Default,,0000,0000,0000,,higher than 3.3 is just respond with “3.3”\Nsaying: “Hey, this is the best I have”.
Dialogue: 0,0:43:18.78,0:43:24.88,Default,,0000,0000,0000,,But turns out a lot of these break.\NSo 3.3 is in the ‘Client Hello’ now, and
Dialogue: 0,0:43:24.88,0:43:30.68,Default,,0000,0000,0000,,3.4 is negotiated as a sub\Nprotocol. So this is messy.
Dialogue: 0,0:43:30.68,0:43:35.61,Default,,0000,0000,0000,,Right? But we do balance the benefits vs.\Ncomplexity, and this is one of the ones
Dialogue: 0,0:43:35.61,0:43:39.64,Default,,0000,0000,0000,,where the benefits of not having servers\Nfail outweigh the complexity added,
Dialogue: 0,0:43:39.64,0:43:44.34,Default,,0000,0000,0000,,of adding an additional thing. And to\Nprevent this from happening in the future
Dialogue: 0,0:43:44.34,0:43:48.82,Default,,0000,0000,0000,,David Benjamin proposed something called\NGREASE where in every single piece of
Dialogue: 0,0:43:48.82,0:43:53.92,Default,,0000,0000,0000,,TLS negotiation you are supposed to,\Nas a client, add some random stuff
Dialogue: 0,0:43:53.92,0:43:56.98,Default,,0000,0000,0000,,in there, so that servers will\Nget used to seeing things
Dialogue: 0,0:43:56.98,0:44:01.05,Default,,0000,0000,0000,,that are not versions they’re used to.\NSo, 0x8a8a. It’s all GREASE-d up!
Dialogue: 0,0:44:01.05,0:44:06.32,Default,,0000,0000,0000,,Filippo: It’s a real thing!\NIt’s a real very useful thing!
Dialogue: 0,0:44:06.32,0:44:08.76,Default,,0000,0000,0000,,Nick: This is going to be very useful,\Nfor the future, for preventing
Dialogue: 0,0:44:08.76,0:44:13.85,Default,,0000,0000,0000,,these sorts of things. But it’s really\Nunfortunate that that had to happen.
Dialogue: 0,0:44:13.85,0:44:18.83,Default,,0000,0000,0000,,We are running low on time, but\Nwe dued to actually get involved with
Dialogue: 0,0:44:18.83,0:44:23.43,Default,,0000,0000,0000,,getting our hands dirty. And one thing\Nthe IETF really loves when developing
Dialogue: 0,0:44:23.43,0:44:28.68,Default,,0000,0000,0000,,these standards is running code. So we\Nstarted with the IETF 95 Hackathon
Dialogue: 0,0:44:28.68,0:44:32.95,Default,,0000,0000,0000,,which is in April, and managed,\Nby the end of it, to get Firefox
Dialogue: 0,0:44:32.95,0:44:37.74,Default,,0000,0000,0000,,to load a server hosted by Cloudflare\Nover TLS 1.3. Which was a big
Dialogue: 0,0:44:37.74,0:44:43.25,Default,,0000,0000,0000,,accomplishment at the time. We used NSS\Nwhich is the security library in Firefox
Dialogue: 0,0:44:43.25,0:44:48.85,Default,,0000,0000,0000,,and ‘Mint’ which was a new version
Dialogue: 0,0:44:48.85,0:44:52.89,Default,,0000,0000,0000,,of TLS 1.3, from scratch, written in Go.
Dialogue: 0,0:44:52.89,0:44:57.64,Default,,0000,0000,0000,,And the result was, it worked! But\Nthis was just a proof-of-concept.
Dialogue: 0,0:44:57.64,0:45:02.95,Default,,0000,0000,0000,,Filippo: To build something that was more\Nproduction ready, we looked at what was
Dialogue: 0,0:45:02.95,0:45:08.33,Default,,0000,0000,0000,,the TLS library that we were most\Nconfident modifying, which unsurprisingly
Dialogue: 0,0:45:08.33,0:45:13.37,Default,,0000,0000,0000,,wasn’t OpenSSL! So we opted to
Dialogue: 0,0:45:13.37,0:45:17.99,Default,,0000,0000,0000,,build 1.3 on top of the Go\Ncrypto/tls library, which is
Dialogue: 0,0:45:17.99,0:45:24.21,Default,,0000,0000,0000,,in the Go language standard library.\NThe result, we call it ‘tls-tris’,
Dialogue: 0,0:45:24.21,0:45:28.50,Default,,0000,0000,0000,,and it’s a drop-in replacement for\Ncrypto/tls, and comes with this
Dialogue: 0,0:45:28.50,0:45:33.97,Default,,0000,0000,0000,,wonderful warning that says “Do not use\Nthis for the sake of everything that’s
Dialogue: 0,0:45:33.97,0:45:38.99,Default,,0000,0000,0000,,good and just!” Now, it used to be about\Neverything, but now it’s not really
Dialogue: 0,0:45:38.99,0:45:45.19,Default,,0000,0000,0000,,about security anymore, we got this\Naudited, but it’s still about stability.
Dialogue: 0,0:45:45.19,0:45:50.51,Default,,0000,0000,0000,,We are working on upstreaming\Nthis, which will solidify the API,
Dialogue: 0,0:45:50.51,0:45:56.00,Default,,0000,0000,0000,,and you can follow along with the\Nupstreaming process. The Google people
Dialogue: 0,0:45:56.00,0:46:00.83,Default,,0000,0000,0000,,were kind enough to open us a branch to do\Nthe development, and it will definitely not
Dialogue: 0,0:46:00.83,0:46:06.96,Default,,0000,0000,0000,,hit the next Go release, Go 1.8, but we\Nare looking forward to upstreaming this.
Dialogue: 0,0:46:06.96,0:46:12.01,Default,,0000,0000,0000,,Anyway, even if you use Go,\Ndeploying is hard.
Dialogue: 0,0:46:12.01,0:46:17.80,Default,,0000,0000,0000,,The first time we deployed Tris\Nthe draft number version was 13.
Dialogue: 0,0:46:17.80,0:46:23.63,Default,,0000,0000,0000,,And to actually support browsers\Ngoing forward from there we had
Dialogue: 0,0:46:23.63,0:46:29.14,Default,,0000,0000,0000,,to support multiple draft versions\Nat the same time by switching on
Dialogue: 0,0:46:29.14,0:46:34.59,Default,,0000,0000,0000,,obscure details sometimes. And sometimes\Nhad to support things that were definitely
Dialogue: 0,0:46:34.59,0:46:40.03,Default,,0000,0000,0000,,not even drafts because\Nbrowsers started to… diverge.
Dialogue: 0,0:46:40.03,0:46:44.97,Default,,0000,0000,0000,,Now, anyway, we had\Na test matrix that would run
Dialogue: 0,0:46:44.97,0:46:50.61,Default,,0000,0000,0000,,all our commits against all the different\Nversions of the client libraries,
Dialogue: 0,0:46:50.61,0:46:54.98,Default,,0000,0000,0000,,and that would make sure that we are\Nalways compatible with the browsers.
Dialogue: 0,0:46:54.98,0:47:00.17,Default,,0000,0000,0000,,And these days the clients are actually\Nmuch more stable, and indeed
Dialogue: 0,0:47:00.17,0:47:05.05,Default,,0000,0000,0000,,you might be already using it\Nwithout knowing. E.g. Chrome Beta,
Dialogue: 0,0:47:05.05,0:47:11.16,Default,,0000,0000,0000,,the beta channel has it enabled for about\N50% as an experiment from the Google side.
Dialogue: 0,0:47:11.16,0:47:16.11,Default,,0000,0000,0000,,And this is how our graphs looked\Nlike when we first launched,
Dialogue: 0,0:47:16.11,0:47:21.56,Default,,0000,0000,0000,,when Firefox Nightly enabled it by default\Nand when Chrome Canary enabled it
Dialogue: 0,0:47:21.56,0:47:26.51,Default,,0000,0000,0000,,by default. These days we are stable,\Naround 700 requests per second
Dialogue: 0,0:47:26.51,0:47:30.64,Default,,0000,0000,0000,,carried over TLS 1.3.\NAnd on our side we enabled it
Dialogue: 0,0:47:30.64,0:47:36.23,Default,,0000,0000,0000,,for millions of our\Nwebsites on Cloudflare.
Dialogue: 0,0:47:36.23,0:47:40.83,Default,,0000,0000,0000,,And, anyway, as we said,\Nthe spec is a living document
Dialogue: 0,0:47:40.83,0:47:46.08,Default,,0000,0000,0000,,and it is open. You can see it on\NGithub. The Tris implementation is there
Dialogue: 0,0:47:46.08,0:47:50.86,Default,,0000,0000,0000,,even if it has this scary warning, and\Nthe blog here is where we’ll probably
Dialogue: 0,0:47:50.86,0:47:56.21,Default,,0000,0000,0000,,publish all the follow-up research and\Nresults of this. Thank you very much and
Dialogue: 0,0:47:56.21,0:47:59.99,Default,,0000,0000,0000,,if you have any questions please come\Nforward, I think we have a few minutes.
Dialogue: 0,0:47:59.99,0:48:11.77,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:48:11.77,0:48:15.69,Default,,0000,0000,0000,,Herald: Thank you, we have plenty\Nof time for questions. First question
Dialogue: 0,0:48:15.69,0:48:19.77,Default,,0000,0000,0000,,goes to the Internet.
Dialogue: 0,0:48:19.77,0:48:23.93,Default,,0000,0000,0000,,Signal Angel: The very first\Nquestion is of people asking if
Dialogue: 0,0:48:23.93,0:48:28.16,Default,,0000,0000,0000,,the decision of the 0-RTT going\Non to the application, handing it
Dialogue: 0,0:48:28.16,0:48:32.45,Default,,0000,0000,0000,,off to the application developers,\Nif that is a very wise decision?
Dialogue: 0,0:48:32.45,0:48:34.13,Default,,0000,0000,0000,,Filippo: {\i1}laughs{\i0}\N{\i1}applause{\i0}
Dialogue: 0,0:48:34.13,0:48:40.23,Default,,0000,0000,0000,,Filippo: Well… fair. So, as we said, this\Nis definitely breaking an abstraction.
Dialogue: 0,0:48:40.23,0:48:45.50,Default,,0000,0000,0000,,So it’s NOT broken by default.\NIf you just update Go
Dialogue: 0,0:48:45.50,0:48:50.79,Default,,0000,0000,0000,,and get TLS 1.3 you won’t\Nget any 0-RTT because
Dialogue: 0,0:48:50.79,0:48:54.80,Default,,0000,0000,0000,,indeed it requires collaboration by the\Napplication. So unless an application
Dialogue: 0,0:48:54.80,0:48:59.98,Default,,0000,0000,0000,,knows what to do with it it just can not\Nuse that and have all the security benefits
Dialogue: 0,0:48:59.98,0:49:06.92,Default,,0000,0000,0000,,and the one round trip full\Nhandshake advantages, anyway.
Dialogue: 0,0:49:06.92,0:49:09.57,Default,,0000,0000,0000,,Herald: Ok, next question\Nis from microphone 1.
Dialogue: 0,0:49:09.57,0:49:12.68,Default,,0000,0000,0000,,Question: With your early testing of the\Nprotocol have you been able to capture
Dialogue: 0,0:49:12.68,0:49:17.61,Default,,0000,0000,0000,,any hard numbers on what those\Nperformance improvements look like?
Dialogue: 0,0:49:17.61,0:49:21.17,Default,,0000,0000,0000,,{\i1}Filippo sighs{\i0}
Dialogue: 0,0:49:21.17,0:49:24.58,Default,,0000,0000,0000,,Nick: One round trip! {\i1}laughs{\i0}\NDepends how much a round trip is.
Dialogue: 0,0:49:24.58,0:49:28.00,Default,,0000,0000,0000,,Filippo: Yeah, exactly. One round trip\Nis… I mean, I can’t tell you a number
Dialogue: 0,0:49:28.00,0:49:33.25,Default,,0000,0000,0000,,because of course if you live in\NSan Francisco with a fast fiber it’s,
Dialogue: 0,0:49:33.25,0:49:39.12,Default,,0000,0000,0000,,I don’t know, 3 milliseconds, 6…?\NIf you live in, I don’t know,
Dialogue: 0,0:49:39.12,0:49:43.26,Default,,0000,0000,0000,,some country where EDGE is the only type\Nof connection you get that’s probably
Dialogue: 0,0:49:43.26,0:49:47.70,Default,,0000,0000,0000,,around one second. I think we have an\Naverage that is around… between 100
Dialogue: 0,0:49:47.70,0:49:55.10,Default,,0000,0000,0000,,and 200 milliseconds, but we haven’t\Nlike formally collected these numbers.
Dialogue: 0,0:49:55.10,0:49:57.63,Default,,0000,0000,0000,,Herald: Ok, next question\Nfrom microphone 3.
Dialogue: 0,0:49:57.63,0:50:01.72,Default,,0000,0000,0000,,Question: One remark I wanted to make is\Nthat another improvement that was made
Dialogue: 0,0:50:01.72,0:50:07.35,Default,,0000,0000,0000,,in TLS 1.3 is that they added\Nencryption to client certificates.
Dialogue: 0,0:50:07.35,0:50:11.33,Default,,0000,0000,0000,,So the client certificates are transmitted\Nencrypted which is important
Dialogue: 0,0:50:11.33,0:50:17.67,Default,,0000,0000,0000,,if you think about that a client will\Nmove, and a dragnet surveillance entity
Dialogue: 0,0:50:17.67,0:50:23.12,Default,,0000,0000,0000,,could track clients with this. And\Nanother remark/question which might…
Dialogue: 0,0:50:23.12,0:50:27.08,Default,,0000,0000,0000,,Herald: Questions are ended with a question\Nmark. So can you keep it please a bit short?
Dialogue: 0,0:50:27.08,0:50:31.82,Default,,0000,0000,0000,,Question: Yeah…\NThat might be stupid so…
Dialogue: 0,0:50:31.82,0:50:36.40,Default,,0000,0000,0000,,Does the fixed Diffie-Hellman\Ngroups… wasn’t that the problem
Dialogue: 0,0:50:36.40,0:50:42.89,Default,,0000,0000,0000,,with the LogJam attack, so… does\Nthis help with LogJam attacks?
Dialogue: 0,0:50:42.89,0:50:46.66,Default,,0000,0000,0000,,Nick: Are you referencing the\Nproposal for the banks?
Dialogue: 0,0:50:46.66,0:50:49.59,Default,,0000,0000,0000,,Question: No no, just in general,\Nthat you can pre-compute…
Dialogue: 0,0:50:49.59,0:50:54.43,Default,,0000,0000,0000,,Nick: Right, yes, so in Logjam there was\Na problem where there was a DH group
Dialogue: 0,0:50:54.43,0:50:57.94,Default,,0000,0000,0000,,that was shared by a lot of different\Nservers by default. The Apache one,
Dialogue: 0,0:50:57.94,0:51:03.80,Default,,0000,0000,0000,,which was 1024 [bit].\NIn TLS 1.3 it was restricted to
Dialogue: 0,0:51:03.80,0:51:09.19,Default,,0000,0000,0000,,a pre-computed DH group, that’s\Nover 2000 bits, as the smallest one,
Dialogue: 0,0:51:09.19,0:51:14.60,Default,,0000,0000,0000,,and even with all the pre-computation in\Nthe world if you have a 2000 bit DH group
Dialogue: 0,0:51:14.60,0:51:20.14,Default,,0000,0000,0000,,it’s not feasible to pre-compute\Nenough to do any type of attack.
Dialogue: 0,0:51:20.14,0:51:21.99,Default,,0000,0000,0000,,But, yeah, that’s a very good point.
Dialogue: 0,0:51:21.99,0:51:24.95,Default,,0000,0000,0000,,Filippo: …and since they are fixed there\Nis no way to force the protocol to use
Dialogue: 0,0:51:24.95,0:51:28.94,Default,,0000,0000,0000,,anything else that would not be as strong.\NQuestion: Okay, thanks!
Dialogue: 0,0:51:28.94,0:51:32.72,Default,,0000,0000,0000,,Herald: Next question for microphone 4.
Dialogue: 0,0:51:32.72,0:51:37.12,Default,,0000,0000,0000,,Question: Thanks for your talk! In the\Nabstract you mentioned that another
Dialogue: 0,0:51:37.12,0:51:41.55,Default,,0000,0000,0000,,feature that had to be killed was SNI,
Dialogue: 0,0:51:41.55,0:51:45.92,Default,,0000,0000,0000,,with the 0-RTT but there are ways to still\Nimplement that, can you elaborate a bit?
Dialogue: 0,0:51:45.92,0:51:49.67,Default,,0000,0000,0000,,Filippo: Yeah. So, we gave this talk\Ninternally twice, and this question came
Dialogue: 0,0:51:49.67,0:51:55.59,Default,,0000,0000,0000,,both of the times. So… {\i1}laughs{\i0}
Dialogue: 0,0:51:55.59,0:52:01.79,Default,,0000,0000,0000,,So, SNI is a small parameter\Nthat the client sends to the server
Dialogue: 0,0:52:01.79,0:52:06.21,Default,,0000,0000,0000,,to say which website it is trying to\Nconnect to. E.g. Cloudflare has
Dialogue: 0,0:52:06.21,0:52:11.25,Default,,0000,0000,0000,,a lot of websites behind our machines, so\Nyou have to tell us “Oh I actually want
Dialogue: 0,0:52:11.25,0:52:17.23,Default,,0000,0000,0000,,to connect to blog.filippo.io”. Now\Nthis is of course a privacy concern
Dialogue: 0,0:52:17.23,0:52:22.55,Default,,0000,0000,0000,,because someone just looking at the bytes\Non the wire will know what specific website
Dialogue: 0,0:52:22.55,0:52:29.45,Default,,0000,0000,0000,,you want to connect to. Now the unfortunate\Nthing is that it has the same problem as
Dialogue: 0,0:52:29.45,0:52:35.27,Default,,0000,0000,0000,,getting forward secrecy for the early\Ndata. You send SNI in the ‘Client Hello’,
Dialogue: 0,0:52:35.27,0:52:39.62,Default,,0000,0000,0000,,and at that time you haven’t negotiated\Nany key yet, so you don’t have anything
Dialogue: 0,0:52:39.62,0:52:44.96,Default,,0000,0000,0000,,to encrypt it with. But if you\Ndon’t send SNI in the first flight
Dialogue: 0,0:52:44.96,0:52:49.14,Default,,0000,0000,0000,,then the server doesn’t know what\Ncertificate to send, so it can’t send
Dialogue: 0,0:52:49.14,0:52:53.05,Default,,0000,0000,0000,,the signature in the first flight! So you\Ndon’t have keys. So you would have to do
Dialogue: 0,0:52:53.05,0:52:59.03,Default,,0000,0000,0000,,a 2-round trip, and now we would\Nbe back at TLS 1.2. So, alas.
Dialogue: 0,0:52:59.03,0:53:03.18,Default,,0000,0000,0000,,That doesn’t work with\N1-round trip handshakes.
Dialogue: 0,0:53:03.18,0:53:08.82,Default,,0000,0000,0000,,Nick: That said, there are proposals in\Nthe HTTP2 spec to allow multiplexing,
Dialogue: 0,0:53:08.82,0:53:14.21,Default,,0000,0000,0000,,and this is ongoing work. It could be\Npossible to establish one connection
Dialogue: 0,0:53:14.21,0:53:19.70,Default,,0000,0000,0000,,to a domain and then establish another\Nconnection within the existing connection.
Dialogue: 0,0:53:19.70,0:53:21.95,Default,,0000,0000,0000,,And that could potentially\Nprotect your SNI.
Dialogue: 0,0:53:21.95,0:53:25.52,Default,,0000,0000,0000,,Filippo: So someone looking would think\Nthat you are going to blog.filippo.io but
Dialogue: 0,0:53:25.52,0:53:29.48,Default,,0000,0000,0000,,then, once you open the connection,\Nyou would be able to ask HTTP2 to also
Dialogue: 0,0:53:29.48,0:53:33.20,Default,,0000,0000,0000,,serve you “this other website”. Thanks!
Dialogue: 0,0:53:33.20,0:53:38.17,Default,,0000,0000,0000,,Herald: Okay, next\Nquestion, microphone 7,
Dialogue: 0,0:53:38.17,0:53:41.24,Default,,0000,0000,0000,,or actually 5, sorry.
Dialogue: 0,0:53:41.24,0:53:47.44,Default,,0000,0000,0000,,Question: You mentioned that there\Nwas formal verification of TLS 1.3.
Dialogue: 0,0:53:47.44,0:53:54.35,Default,,0000,0000,0000,,What’s the software that was used\Nto do the formal verification?
Dialogue: 0,0:53:54.35,0:53:59.03,Default,,0000,0000,0000,,Nick: So there were several software\Nimplementations and protocols…
Dialogue: 0,0:53:59.03,0:54:02.65,Default,,0000,0000,0000,,Let’s see if I can go back… here.
Dialogue: 0,0:54:02.65,0:54:06.60,Default,,0000,0000,0000,,So, Tamarin[Prover] is a piece of software\Ndeveloped by Cas Cremers and others,
Dialogue: 0,0:54:06.60,0:54:11.81,Default,,0000,0000,0000,,at Oxford and Royal Holloway.\NmiTLS is in F# I believe,
Dialogue: 0,0:54:11.81,0:54:18.43,Default,,0000,0000,0000,,this is by INRIA.\NAnd NQSB-TLS is in OCAMAL.
Dialogue: 0,0:54:18.43,0:54:22.97,Default,,0000,0000,0000,,So several different languages were used\Nto develop these and I believe the authors
Dialogue: 0,0:54:22.97,0:54:27.49,Default,,0000,0000,0000,,of NQSB-TLS are here…
Dialogue: 0,0:54:27.49,0:54:30.96,Default,,0000,0000,0000,,Herald: Okay, next question, microphone 8.
Dialogue: 0,0:54:30.96,0:54:36.44,Default,,0000,0000,0000,,Question: Hi! Thanks. Thank you for\Nyour informative presentation.
Dialogue: 0,0:54:36.44,0:54:42.69,Default,,0000,0000,0000,,SSL and TLS history is riddled with “what\Ncould possibly go wrong” ideas and moments
Dialogue: 0,0:54:42.69,0:54:48.81,Default,,0000,0000,0000,,that bit us in the ass eventually. And so\NI guess my question is taking into account
Dialogue: 0,0:54:48.81,0:54:52.74,Default,,0000,0000,0000,,that there’s a lot of smaller organisations\Nor smaller hosting companies etc. that
Dialogue: 0,0:54:52.74,0:54:59.60,Default,,0000,0000,0000,,will probably get this 0-RTT thing\Nwrong. Your gut feeling? How large
Dialogue: 0,0:54:59.60,0:55:04.18,Default,,0000,0000,0000,,a chance is there that this will indeed\Nbite us in the ass soon? Thank you.
Dialogue: 0,0:55:04.18,0:55:09.99,Default,,0000,0000,0000,,Filippo: Ok, so, as I said I’m\Nactually vaguely sceptical
Dialogue: 0,0:55:09.99,0:55:16.46,Default,,0000,0000,0000,,on the impact on HTTP because browsers\Ncan be made to replay requests already.
Dialogue: 0,0:55:16.46,0:55:21.61,Default,,0000,0000,0000,,And we have seen papers\Nand blog posts about it. But
Dialogue: 0,0:55:21.61,0:55:25.83,Default,,0000,0000,0000,,no one actually went out\Nand proved that that broke
Dialogue: 0,0:55:25.83,0:55:30.62,Default,,0000,0000,0000,,a huge percent of the internet. But to\Nbe honest, I actually don’t know how to
Dialogue: 0,0:55:30.62,0:55:35.99,Default,,0000,0000,0000,,answer you how badly we will be bit by it.\NBut remember that on the other hand
Dialogue: 0,0:55:35.99,0:55:41.65,Default,,0000,0000,0000,,of the balance is how many still say\Nthat they won’t implement TLS
Dialogue: 0,0:55:41.65,0:55:45.67,Default,,0000,0000,0000,,because it’s “slow”. Now, no!
Dialogue: 0,0:55:45.67,0:55:51.62,Default,,0000,0000,0000,,It’s 0-RTT, TLS is fast! Go\Nout and encrypt everything!
Dialogue: 0,0:55:51.62,0:55:57.94,Default,,0000,0000,0000,,So those are the 2 concerns that\Nyou have to balance together.
Dialogue: 0,0:55:57.94,0:56:01.91,Default,,0000,0000,0000,,Again, my personal opinion\Nis also worth very little.
Dialogue: 0,0:56:01.91,0:56:07.31,Default,,0000,0000,0000,,This was a decision that was made by\Nthe entire community on the mailing list.
Dialogue: 0,0:56:07.31,0:56:12.90,Default,,0000,0000,0000,,And I can assure you that everyone has\Nbeen really conservative with everything,
Dialogue: 0,0:56:12.90,0:56:18.63,Default,,0000,0000,0000,,thinking even… indeed, if the name\Nwould have mislead people. So,
Dialogue: 0,0:56:18.63,0:56:23.91,Default,,0000,0000,0000,,I can’t predict the future. I can only\Nsay that I hope we made the best choice
Dialogue: 0,0:56:23.91,0:56:28.52,Default,,0000,0000,0000,,to make the most part of the\Nweb the most secure we can.
Dialogue: 0,0:56:28.52,0:56:32.49,Default,,0000,0000,0000,,Herald: Next question is from the internet.
Dialogue: 0,0:56:32.49,0:56:34.61,Default,,0000,0000,0000,,Signal Angel, do we have another\Nquestion from the internet?
Dialogue: 0,0:56:34.61,0:56:37.76,Default,,0000,0000,0000,,Signal Angel: Yes we do.
Dialogue: 0,0:56:37.76,0:56:43.06,Default,,0000,0000,0000,,What are the major implementation\Nincompatibilities that were found
Dialogue: 0,0:56:43.06,0:56:45.80,Default,,0000,0000,0000,,now that the actual spec is fairly close?
Dialogue: 0,0:56:45.80,0:56:47.91,Default,,0000,0000,0000,,Herald: Can you repeat that question?
Dialogue: 0,0:56:47.91,0:56:53.25,Default,,0000,0000,0000,,{\i1}Signal Angel repeats question{\i0}
Dialogue: 0,0:56:53.25,0:56:59.29,Default,,0000,0000,0000,,Filippo: Okay. As in\Nduring the drafts period?
Dialogue: 0,0:56:59.29,0:57:03.45,Default,,0000,0000,0000,,So, some of the ones that had version\Nintolerance were mostly, I think,
Dialogue: 0,0:57:03.45,0:57:06.75,Default,,0000,0000,0000,,middle boxes and firewalls.
Dialogue: 0,0:57:06.75,0:57:12.69,Default,,0000,0000,0000,,Nick: There were some very large sites.\NI think Paypal was one of them?
Dialogue: 0,0:57:12.69,0:57:18.31,Default,,0000,0000,0000,,Filippo: Although during the process we\Nhad incompatibilities for all kinds of
Dialogue: 0,0:57:18.31,0:57:23.54,Default,,0000,0000,0000,,reasons, including one of\Nthe 2 developers misspelled
Dialogue: 0,0:57:23.54,0:57:28.11,Default,,0000,0000,0000,,the variable number.\N{\i1}laughs{\i0}
Dialogue: 0,0:57:28.11,0:57:32.42,Default,,0000,0000,0000,,During the drafts sometimes compatibility\Nbroke, but there was a lot of
Dialogue: 0,0:57:32.42,0:57:37.97,Default,,0000,0000,0000,,collaboration between client implementations\Nand server implementations on our side.
Dialogue: 0,0:57:37.97,0:57:44.04,Default,,0000,0000,0000,,So I’m pretty happy to say that the\Nactual 1.3 implementations had a lot of
Dialogue: 0,0:57:44.04,0:57:50.98,Default,,0000,0000,0000,,interoperability testing, and all the\Nissues were pretty quick to be killed.
Dialogue: 0,0:57:50.98,0:57:54.05,Default,,0000,0000,0000,,Herald: Okay, next question\Nis from microphone number 1.
Dialogue: 0,0:57:54.05,0:57:59.30,Default,,0000,0000,0000,,Question: I have 2 quick questions\Nconcerning session resumption.
Dialogue: 0,0:57:59.30,0:58:02.95,Default,,0000,0000,0000,,If you store some data on a server\Nfrom a session, wouldn’t that be
Dialogue: 0,0:58:02.95,0:58:08.01,Default,,0000,0000,0000,,some kind of supercookie?\NIs that not privacy-dangerous?
Dialogue: 0,0:58:08.01,0:58:13.99,Default,,0000,0000,0000,,And the second question would be: what\Nabout DNS load balancers or some other
Dialogue: 0,0:58:13.99,0:58:21.07,Default,,0000,0000,0000,,huge amounts of servers where your request\Nis going to different servers every time?
Dialogue: 0,0:58:21.07,0:58:28.15,Default,,0000,0000,0000,,Filippo: Ok, so, these are details about\Ndeploying session tickets effectively.
Dialogue: 0,0:58:28.15,0:58:32.95,Default,,0000,0000,0000,,TLS 1.3 does think about the privacy\Nconcerns of session tickets; and indeed
Dialogue: 0,0:58:32.95,0:58:37.65,Default,,0000,0000,0000,,it allows the server to send multiple\Nsession tickets. So the server will still
Dialogue: 0,0:58:37.65,0:58:42.47,Default,,0000,0000,0000,,know what client is sending it if it\Nwants to. But at least anyone looking
Dialogue: 0,0:58:42.47,0:58:47.46,Default,,0000,0000,0000,,at the connection since they are\Nsent encrypted, not like in 1.2, and
Dialogue: 0,0:58:47.46,0:58:53.17,Default,,0000,0000,0000,,there can be many. Anyone looking at the\Nconnection will not be able to link it
Dialogue: 0,0:58:53.17,0:58:57.60,Default,,0000,0000,0000,,back to the original connection. That’s\Nthe best you can do, because if the server
Dialogue: 0,0:58:57.60,0:59:02.56,Default,,0000,0000,0000,,and the client have to reuse some shared\Nknowledge the server has to learn about
Dialogue: 0,0:59:02.56,0:59:08.24,Default,,0000,0000,0000,,who it was. But session tickets in 1.3\Ncan’t be tracked by a passive observer,
Dialogue: 0,0:59:08.24,0:59:13.01,Default,,0000,0000,0000,,by a third party, actually. And… when you\Ndo load balancing… there is an interesting
Dialogue: 0,0:59:13.01,0:59:18.75,Default,,0000,0000,0000,,paper about deploying session tickets,\Nbut the gist is that you probably want
Dialogue: 0,0:59:18.75,0:59:24.96,Default,,0000,0000,0000,,to figure out how clients roam between\Nyour servers, and strike a balance between
Dialogue: 0,0:59:24.96,0:59:30.34,Default,,0000,0000,0000,,having to share the session ticket\Nkey so that it’s more effective, and
Dialogue: 0,0:59:30.34,0:59:35.50,Default,,0000,0000,0000,,not sharing the session ticket key which\Nmakes it harder to acquire them all.
Dialogue: 0,0:59:35.50,0:59:41.61,Default,,0000,0000,0000,,You might want to do geographically\Nlocated, or in-a-single-rack…
Dialogue: 0,0:59:41.61,0:59:44.54,Default,,0000,0000,0000,,it’s really up to the deployment.
Dialogue: 0,0:59:44.54,0:59:47.48,Default,,0000,0000,0000,,Herald: Okay, final question\Ngoes to microphone 3.
Dialogue: 0,0:59:47.48,0:59:51.75,Default,,0000,0000,0000,,Question: I have a question regarding the\NGREASE mechanism that is implemented
Dialogue: 0,0:59:51.75,0:59:57.11,Default,,0000,0000,0000,,on the client side. If I understood\Nit correctly you are inserting
Dialogue: 0,0:59:57.11,1:00:02.35,Default,,0000,0000,0000,,random version numbers of\Nnot-existing TLS or SSL versions
Dialogue: 0,1:00:02.35,1:00:08.64,Default,,0000,0000,0000,,and that way training\Nthe servers to
Dialogue: 0,1:00:08.64,1:00:14.48,Default,,0000,0000,0000,,conform to the specification. What\Nis the result of the real-world tests?
Dialogue: 0,1:00:14.48,1:00:18.49,Default,,0000,0000,0000,,How many servers actually\Nare broken by this?
Dialogue: 0,1:00:18.49,1:00:22.78,Default,,0000,0000,0000,,Filippo: So you would expect none because\Nafter all they are all implementing 1.3
Dialogue: 0,1:00:22.78,1:00:28.07,Default,,0000,0000,0000,,now, so that all the clients they would\Nsee would already be doing GREASE. Instead
Dialogue: 0,1:00:28.07,1:00:33.10,Default,,0000,0000,0000,,just as Google enabled GREASE I think\Nit broke… I’m not sure so I won’t say
Dialogue: 0,1:00:33.10,1:00:38.33,Default,,0000,0000,0000,,which specific server implementation, but\None of the minor server implementations
Dialogue: 0,1:00:38.33,1:00:41.86,Default,,0000,0000,0000,,was immediately detected\Nas… the Haskell one!
Dialogue: 0,1:00:41.86,1:00:43.89,Default,,0000,0000,0000,,Nick: Right!\NFilippo: I don’t remember the name,
Dialogue: 0,1:00:43.89,1:00:47.45,Default,,0000,0000,0000,,I can’t read Haskell, so I don’t know what\Nexactly they were doing, but they were
Dialogue: 0,1:00:47.45,1:00:49.59,Default,,0000,0000,0000,,terminating connections because of GREASE.
Dialogue: 0,1:00:49.59,1:00:53.48,Default,,0000,0000,0000,,Nick: And just as a note, GREASE is also\Nused in cipher negotiation and anything
Dialogue: 0,1:00:53.48,1:00:58.80,Default,,0000,0000,0000,,that is a negotiation in TLS 1.3.\NSo this actually did break
Dialogue: 0,1:00:58.80,1:01:03.02,Default,,0000,0000,0000,,a subset of servers, but\Na small enough subset
Dialogue: 0,1:01:03.02,1:01:06.60,Default,,0000,0000,0000,,that people were happy with it.
Dialogue: 0,1:01:06.60,1:01:08.67,Default,,0000,0000,0000,,Question: Thanks!\NNick: 2% is too high!
Dialogue: 0,1:01:08.67,1:01:11.43,Default,,0000,0000,0000,,Herald: Thank you very much.\NFilippo: Thank you!
Dialogue: 0,1:01:11.43,1:01:20.01,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,1:01:20.01,1:01:39.08,Default,,0000,0000,0000,,{\i1}33C3 postroll music{\i0}
Dialogue: 0,1:01:39.08,1:01:43.98,Default,,0000,0000,0000,,{\i1}subtitles created by c3subtitles.de\Nin the year 2017. Join, and help us!{\i0}