WEBVTT 00:00.000 --> 00:06.640 All right, so I'll give the joke away. 00:06.640 --> 00:08.800 Hi, so my name's Lars, I work from Azilla. 00:08.800 --> 00:11.800 I do security privacy networking. 00:11.800 --> 00:13.000 This is a talk. 00:13.000 --> 00:15.000 It's a particular take over from the network 00:15.000 --> 00:15.400 deference. 00:15.400 --> 00:18.720 So there's not going to be a lot of AI and LLMs in this talk. 00:18.720 --> 00:20.720 So I apologize for that ahead of time. 00:20.720 --> 00:22.200 It's not aligned with the company goals 00:22.200 --> 00:25.520 with 2025, but we also, like, send network traffic, 00:25.520 --> 00:28.280 and I think it's important that we talk about that too. 00:28.280 --> 00:32.240 So when I submitted the talk, I called it quick versus middle boxes, 00:32.240 --> 00:36.200 and then I reconsidered, and I thought it was very adversarial. 00:36.200 --> 00:37.200 And that's not what we are. 00:37.200 --> 00:39.600 So we actually love the middle boxes. 00:39.600 --> 00:41.000 And we love the middle boxes so much 00:41.000 --> 00:42.160 of you do special things for them. 00:42.160 --> 00:44.240 And I'm going to talk a little bit about what those are 00:44.240 --> 00:47.440 and why we're doing them. 00:47.440 --> 00:49.160 Right, so agenda is pretty obvious. 00:49.160 --> 00:49.720 It's about quick. 00:49.720 --> 00:52.200 It's about middle boxes than about the law of we give them. 00:52.200 --> 00:56.720 Can I sort of get a feeling like who knows what quick is at some level? 00:56.720 --> 00:58.160 OK, who knows what a middle box is? 00:58.160 --> 01:00.120 At some level, fewer people. 01:00.120 --> 01:02.400 OK, because I have too many slides and I need to go 01:02.400 --> 01:03.400 to go fast somewhere. 01:03.400 --> 01:06.000 So we'll see what it goes. 01:06.000 --> 01:08.560 So a little bit of a reminder of quick. 01:08.560 --> 01:12.440 So quick is a fast, secure, evolveable internet transport. 01:12.440 --> 01:15.160 What if an internet fast means it should at least deliver 01:15.160 --> 01:20.400 the same performance as TCP and TLS have for HTTP2, ideally, 01:20.400 --> 01:23.800 it should be better, because otherwise, why bother? 01:23.800 --> 01:24.720 It should be evolveable. 01:24.720 --> 01:27.760 One of the problems we have with H2 and TCPTLS 01:27.760 --> 01:33.200 is that specifically TCP has sort of been around the network for a long time. 01:33.200 --> 01:36.480 And so the network has classified to use a geological term 01:36.480 --> 01:39.760 around an impression of what TCP package should look like. 01:39.760 --> 01:41.520 And if you're sending TCP packets that 01:41.520 --> 01:44.320 looks slightly different, then many middle boxes 01:44.320 --> 01:46.280 think they should look like they get dropped. 01:46.280 --> 01:47.760 So it's terrible for evolution. 01:47.760 --> 01:50.000 And we quickly really wanted to avoid this, which 01:50.000 --> 01:52.760 is one reason why we're encrypting almost everything 01:52.760 --> 01:54.640 in the quick protocol. 01:54.640 --> 01:56.400 The other reasons that we want to be secure, 01:56.400 --> 02:00.640 right, ideally, as secure again, a TCPTLS, and better. 02:00.640 --> 02:02.000 Energy via transport protocol. 02:02.000 --> 02:04.720 While H3 is probably the most important workload, 02:04.720 --> 02:07.400 it was pretty clear when we started with quick 02:07.400 --> 02:10.080 that we wanted to support other things 02:10.080 --> 02:12.520 that aren't encapsulated in HDP. 02:12.520 --> 02:16.160 So in theory, you can run quick as a multi-stream transfer 02:16.160 --> 02:20.160 protocol and not bother with actually carrying HDP. 02:20.160 --> 02:23.000 That's small use cases, but they do exist. 02:23.000 --> 02:24.640 So that's what I mean by transport. 02:26.560 --> 02:30.480 This is roughly on the left-hand side how the stack used 02:30.480 --> 02:34.600 look evolved from HDP11 that had maybe TLS or SSL. 02:34.600 --> 02:36.880 If you go back all the way over TCP, 02:36.880 --> 02:39.800 and then the current sort of or old-style web stack 02:39.800 --> 02:44.800 with H2, TCPTLS122, and then on the right-hand side, 02:44.800 --> 02:47.920 the colorful new thing, which is HDP3, providing the HDP 02:47.920 --> 02:50.080 semantics on top of the quick protocol that 02:50.080 --> 02:51.960 encapsulates TLS13. 02:51.960 --> 02:53.520 So it's not another layer. 02:53.520 --> 02:55.600 It's sort of in there somewhere. 02:55.600 --> 02:58.120 And it runs on top of UDP. 02:58.120 --> 03:00.840 And the timeline very roughly is the Google experiment 03:00.840 --> 03:03.480 sort of started in 2013, three years later, 03:03.480 --> 03:05.280 they came to the ITF. 03:05.280 --> 03:07.280 We had a very interesting meeting. 03:07.280 --> 03:09.880 And we decided, yeah, we're going to take this forward. 03:09.880 --> 03:12.720 And then the ITF work group started in five years later, 03:12.720 --> 03:15.720 which for the ITF is super fast, just the level set 03:15.720 --> 03:17.360 expectations here. 03:17.360 --> 03:19.880 We had a bunch of IRCs and quick as now a standard. 03:19.880 --> 03:22.720 And this is a cloud set over the last, I think, 12 months. 03:22.720 --> 03:26.440 And it shows sort of the light blue is H3. 03:26.440 --> 03:31.000 Around 30% of the web is HDP3 at the moment, 03:31.000 --> 03:34.080 which is not bad considering that it became an RFC 03:34.080 --> 03:35.080 like four years ago. 03:35.080 --> 03:37.360 So that's what quick is. 03:37.360 --> 03:39.320 Why did we do UDP? 03:39.320 --> 03:41.720 The short answer is UDP is all that's left. 03:41.720 --> 03:43.520 Middle boxes I mentioned before. 03:43.520 --> 03:46.040 The only thing that led through is typically TCP. 03:46.040 --> 03:47.960 We had dreams in the ITF a long time ago 03:47.960 --> 03:50.080 that we would do SETP or DCCP, 03:50.080 --> 03:52.240 or that would be these other protocols. 03:52.240 --> 03:55.600 That's why the IP protocol has this type field 03:55.600 --> 03:56.720 where it comes next. 03:56.720 --> 03:59.080 And in reality, everything that isn't UDP or TCP 03:59.080 --> 03:59.640 gets dropped. 03:59.640 --> 04:02.880 So we couldn't do TCP because of the application, 04:02.880 --> 04:03.960 so UDP is left. 04:03.960 --> 04:06.160 And there's some issues with that because the network has 04:06.160 --> 04:08.000 classified also around UDP. 04:08.000 --> 04:11.200 There's an assumption that UDP is really only for DNS. 04:11.200 --> 04:13.000 And so you don't need to sustain 04:13.000 --> 04:14.160 like long-lived flows, right? 04:14.160 --> 04:17.480 These are request response things that's going over UDP, of course. 04:17.480 --> 04:18.280 So there's some issues. 04:18.280 --> 04:19.280 But there's also benefits. 04:19.280 --> 04:20.760 You can deploy in user space. 04:20.760 --> 04:22.240 So you don't need to modify the kernel 04:22.240 --> 04:24.480 if you want to upgrade your quick stack. 04:24.480 --> 04:27.720 And you can also, because you can freely modify 04:27.720 --> 04:30.720 your quick implementation, you can offer alternative transport 04:30.720 --> 04:32.680 types, not just like a byte stream, like TCP, 04:32.680 --> 04:34.920 but other things. 04:34.920 --> 04:36.120 Why do we congestion control? 04:36.120 --> 04:38.680 The answer is that we do, it's the internet. 04:38.680 --> 04:40.480 I don't want to go into this detail. 04:40.480 --> 04:42.440 This is apparently a photo of a Chinese highway, 04:42.440 --> 04:45.480 which shows you why congestion control matters, 04:45.480 --> 04:48.720 not only in the network. 04:48.720 --> 04:51.320 Why do we want to TLS? 04:51.320 --> 04:54.320 Again, everybody knows building your own crypto is bad. 04:54.320 --> 04:55.680 Five minutes left. 04:55.680 --> 04:57.440 That seems optimistic. 04:57.440 --> 05:00.240 So we want to use TLS. 05:00.240 --> 05:01.840 Right, mailboxes. 05:01.840 --> 05:03.400 They're metal. 05:03.400 --> 05:04.880 They're metal in good ways. 05:04.880 --> 05:06.320 So there's these TCP accelerators. 05:06.320 --> 05:08.320 So if you have geostationized satellites, 05:08.320 --> 05:10.880 they make that work by lying to the insistence 05:10.880 --> 05:13.760 about what the path looks like, which is great, 05:13.760 --> 05:17.280 but also terrible because they do really bad things 05:17.280 --> 05:18.680 to all kinds of traffic. 05:18.680 --> 05:20.000 But there's also these things. 05:20.000 --> 05:22.840 Quant to insert the NSA full take. 05:22.840 --> 05:25.160 There's the great firewall that people have heard about. 05:25.160 --> 05:27.240 There's a great paper that talks about the great canon. 05:27.240 --> 05:29.280 If you haven't read that paper, read it. 05:29.280 --> 05:30.120 It's great. 05:30.120 --> 05:33.720 China basically weaponizes arbitrary website 05:33.720 --> 05:36.280 by injecting JavaScript through the great firewall 05:36.280 --> 05:39.600 that then turns the clients into dedos machines, 05:39.600 --> 05:40.920 not in China, but elsewhere. 05:40.920 --> 05:42.680 So it's fascinating, read it. 05:42.680 --> 05:44.960 So these sort of attacks are sort of not great. 05:44.960 --> 05:48.280 And we want to do something against those kinds of middle boxes. 05:48.280 --> 05:50.840 And there's no denn, like the ITF, we decided, 05:50.840 --> 05:52.440 because we had a kings of the internet apparently, 05:52.440 --> 05:54.400 that progressive monitoring is an attacker. 05:54.400 --> 05:55.600 We're going to do something. 05:55.600 --> 05:56.520 What does something mean? 05:56.520 --> 05:57.920 We're going to encrypt as much as possible. 05:57.920 --> 05:59.400 But what else could we do? 05:59.400 --> 06:03.280 And this is what we're getting to with a lot of. 06:03.280 --> 06:05.240 TLS extension randomization is a thing. 06:05.240 --> 06:07.440 It's not super great, but it's part for the course. 06:07.440 --> 06:08.680 You do it. 06:08.680 --> 06:10.400 It's extensions that make your finger printables. 06:10.400 --> 06:14.640 So if you randomize it, you'd bit less finger printable, maybe. 06:14.640 --> 06:15.680 This slide was out of order. 06:15.680 --> 06:17.520 There's Greece, which is this concept that 06:17.520 --> 06:20.800 it used to say in the RFCs, if you read them, right? 06:20.800 --> 06:22.920 You must set these bits to zero because they're 06:22.920 --> 06:26.840 for future sensibility, and you must ignore them when you read them. 06:26.840 --> 06:28.680 And that works great, except every middle box drops, 06:28.680 --> 06:32.040 every packet that isn't zero in those code points, right? 06:32.040 --> 06:33.640 So that, in practice, doesn't work at all. 06:33.640 --> 06:35.760 So we decided you must make them random, 06:35.760 --> 06:38.520 and you must ignore them, and that works better. 06:38.520 --> 06:42.000 But we also have various other ways in which we 06:42.000 --> 06:45.200 Greece, the protocols at the network, doesn't see any bit 06:45.200 --> 06:48.480 patterns that don't change, which is the thing that breaks 06:48.480 --> 06:50.360 sensibility. 06:50.360 --> 06:52.400 TLS SNI observability is a problem. 06:52.400 --> 06:55.680 SNI is basically the name of the website you're talking to. 06:55.680 --> 06:57.840 It's an ASCII string that's in the first packet, which 06:57.840 --> 07:01.400 is not great, easily observable. 07:01.400 --> 07:03.960 There's encrypted client to a low, which is great. 07:03.960 --> 07:06.880 It's complicated, but basically it means there's an inner SNI 07:06.880 --> 07:08.800 and an outer SNI, the inner one is encrypted. 07:08.800 --> 07:10.640 The outer one, if you're using cloud tolay, 07:10.640 --> 07:13.280 which is at the moment, basically, the only CD end, 07:13.280 --> 07:14.120 it has this enabled. 07:14.120 --> 07:16.720 It says cloudflared.ech.com, which is great, 07:16.720 --> 07:18.680 because they don't know you go to Mozilla to come, 07:18.680 --> 07:20.480 but they do know you're using ECH, so they're going 07:20.480 --> 07:22.280 to drop you, because you're using ECH, 07:22.280 --> 07:25.520 just what Russia is doing right now, for example. 07:25.520 --> 07:27.480 So what can we do? 07:27.480 --> 07:31.280 SNI application Chrome causes chaos protection. 07:31.280 --> 07:35.440 With quick, the crypto stuff are chunkable, 07:35.440 --> 07:38.080 so we can basically, we don't have to carry the full client 07:38.080 --> 07:41.840 below, we can slice it and dice it and send stuff out of order. 07:41.840 --> 07:44.840 So for example, Mozilla to come becomes something 07:44.840 --> 07:47.720 that isn't as easily recognizable as Mozilla to come. 07:47.720 --> 07:50.000 And with bonus with post-quand of crypto, 07:50.000 --> 07:54.040 the client alone needs multiple packets, because big certs. 07:54.040 --> 07:56.640 That means we have multiple physical packets we need to send, 07:56.640 --> 07:58.160 so we can slice and dice the SNI, 07:58.160 --> 08:01.880 and other interesting bits of data, over multiple packets, 08:01.880 --> 08:04.240 and force the mailboxes to keep state. 08:04.240 --> 08:06.680 So they need to store the packets, we order the data, 08:06.680 --> 08:09.240 we assemble it, and then they can maybe read the SNI. 08:09.240 --> 08:13.240 So it's not protection, but it just makes it a little bit more annoying. 08:13.240 --> 08:17.800 And the hope is that middle boxes that are on donation states, 08:17.800 --> 08:21.320 they want to do this for every, for all the traffic, 08:21.320 --> 08:23.160 needs to spend a bit more bucks to do this, 08:23.160 --> 08:26.520 which is pretty much the best we can hope for. 08:26.520 --> 08:27.960 There's a better draft, Mike Thompson, 08:27.960 --> 08:30.760 of extremism, as Mark Guy has a proposal that, 08:30.760 --> 08:33.040 I don't think, has been submitted to the ITF, 08:33.040 --> 08:35.880 but you can find it if you look for that string, 08:35.880 --> 08:38.760 which uses clever crypto to actually 08:38.760 --> 08:41.640 masquerade the SNI more fully. 08:41.640 --> 08:44.200 So not just slice and dice it in and make it obfuscated, 08:44.200 --> 08:45.840 but actually like I did. 08:45.840 --> 08:47.640 It's really good, I think it's great. 08:47.640 --> 08:51.160 We should do it, requires support from the servers. 08:51.160 --> 08:53.080 Zero is a fun and profit, that's my last slide. 08:53.080 --> 08:56.040 So a great paper about the great firewall again, 08:56.040 --> 08:58.000 on the bottom, one of those researchers, email does this, 08:58.000 --> 09:00.680 why does your quick stack pad with zeros? 09:00.680 --> 09:03.240 Everybody else paths random, and we said, 09:03.240 --> 09:05.160 because doesn't matter, and he said, 09:05.720 --> 09:08.120 that makes your packets go through the great firewall at the moment. 09:08.120 --> 09:10.680 And the reason is that the great firewall has some very simple 09:10.680 --> 09:12.680 usestics to identify all encrypted traffic. 09:12.680 --> 09:15.720 And one year is the guess, the amount of zeros in ones 09:15.720 --> 09:18.840 in terms of bits in the packet is roughly the same. 09:18.840 --> 09:20.760 And if you pad by zeros, it's not. 09:20.760 --> 09:23.080 There's a lot more zero bits in that packet. 09:23.080 --> 09:26.200 And so, yeah, they use very simple usestics like that, 09:26.200 --> 09:27.800 because they're cheap and they're effective. 09:27.800 --> 09:29.080 That's how they scale out, right? 09:29.080 --> 09:33.800 So anything you can do to make those things harder are wins. 09:33.800 --> 09:36.480 And so, be keep padding with zeros, 09:36.480 --> 09:39.440 and we're trying to find other things that we can do. 09:39.440 --> 09:41.520 So A, I'm going to thank you guys for being great audience. 09:41.520 --> 09:44.720 B, if you're interested in work on these things, 09:44.720 --> 09:49.240 we're contactable on GitHub and on other places. 09:49.240 --> 09:53.280 If you have the ability to test, quick, or Firefox 09:53.280 --> 09:56.440 in interesting regions, or in interesting networks, 09:56.440 --> 09:59.720 contact me, be happy to send you a thing you can run 09:59.720 --> 10:03.520 on a command line and tell me whether it works or not. 10:03.520 --> 10:04.520 Thank you. 10:04.520 --> 10:05.520 Thank you, we are match. 10:11.520 --> 10:13.120 Raise your hand if you have a question. 10:17.840 --> 10:19.600 Have you had any issues with don't you virus 10:19.600 --> 10:22.400 software intersecting the threat? 10:22.400 --> 10:25.160 Yeah, that's a little, so inside joke is that so, 10:25.160 --> 10:27.680 so one of the reasons we also interested in this is that 10:27.680 --> 10:30.640 one of the spikes we saw earlier in the crash reports 10:30.640 --> 10:33.000 was that we had a bug in the quick stack 10:33.000 --> 10:35.280 that we haven't ever hit before, 10:35.280 --> 10:36.840 which is basically we're getting an acknowledgement 10:36.840 --> 10:38.640 for packets we never sent. 10:38.640 --> 10:41.640 That doesn't really happen, right, because you know, 10:41.640 --> 10:43.480 but there was an entire virus system 10:43.480 --> 10:45.600 that's pretty widely employed on Windows 10:45.600 --> 10:49.200 that getting in the middle of the quick flow 10:49.200 --> 10:51.000 was marking with the packets. 10:51.000 --> 10:53.280 God confused, says, I'm out of here, 10:53.280 --> 10:55.720 let these guys talk again at the endpoints. 10:55.720 --> 10:59.240 And so, the server things, it's seen a packet 10:59.240 --> 11:01.000 that we never send and it sends us an packet. 11:01.000 --> 11:05.080 We go crash, right, so good thing is we found it quickly. 11:05.080 --> 11:07.960 It was a top pressure, I think, for a little while. 11:07.960 --> 11:12.440 But then, so yeah, we want also those middle boxes 11:12.440 --> 11:15.120 that are anti-virus systems basically out of the way. 11:15.120 --> 11:16.600 Not so much because I don't trust them 11:16.600 --> 11:18.960 and you know, people installed them for the reasons it, 11:18.960 --> 11:20.920 but you know, they have bugs too. 11:20.920 --> 11:23.200 And specifically also I'm worried about the performance bugs 11:23.200 --> 11:27.200 because the kernel TCP stack is on all platforms really good 11:27.200 --> 11:29.720 and if a proxy uses that or one of those 11:29.720 --> 11:32.120 inspection things uses that, that's great. 11:32.120 --> 11:33.240 But they have their own quick stack, 11:33.240 --> 11:36.040 which uses the user level library to send network traffic. 11:36.040 --> 11:38.040 I have no idea how good the performance of that is. 11:38.040 --> 11:40.680 Probably not as good as the servers and the clients. 11:40.680 --> 11:42.720 And so I want them out of the way. 11:42.720 --> 11:44.000 Thank you for that room, minor. 11:44.000 --> 11:44.840 Thank you. 11:44.840 --> 11:45.840 We have more questions. 11:49.480 --> 11:51.720 I don't see any hands, okay, cool. 11:51.720 --> 11:53.640 Do we have anything in the chat? 11:53.640 --> 11:54.480 Thank you very much.