WEBVTT 00:00.000 --> 00:12.000 So, hi everyone. 00:12.000 --> 00:17.440 So my name is Ruben, last name Neville for anyone Dutch. 00:17.440 --> 00:24.720 So I work at the Traffected Tech Foundation, which is a Dutch non-profit organization. 00:24.720 --> 00:33.160 We do most of our work on open infrastructure software for the internet. 00:33.160 --> 00:42.600 My own focus is on time synchronization software, which is NTP clients and server, and 00:42.600 --> 00:55.560 step-time, which is our PTP library, and at least for now, our PTP Linux server and clients. 00:55.560 --> 01:02.160 But today I want to talk to you about our NTS pool project. 01:02.160 --> 01:08.200 And before I do that, I just see a show of hands, who here would be able to tell the 01:08.200 --> 01:10.200 current time right now. 01:10.200 --> 01:12.200 Anyone? 01:12.200 --> 01:14.200 Yeah. 01:14.200 --> 01:20.200 Some people are not so sure anymore, since I asked the question. 01:20.200 --> 01:24.200 Let me quickly go over what I was looking for. 01:24.200 --> 01:28.200 What I was looking for actually was time in UTC. 01:28.200 --> 01:30.200 UTC is the worldwide standard. 01:30.200 --> 01:35.200 All countries in the world use UTC for time. 01:36.200 --> 01:41.200 And actually on the slide, there's a picture here of three boxes. 01:41.200 --> 01:43.200 Those are three atomic clocks. 01:43.200 --> 01:45.200 There are about two kilometers that way. 01:45.200 --> 01:51.200 They are the Belgian servers for determining UTC. 01:51.200 --> 01:57.200 In total, there are some 400 of these boxes and all of them together. 01:57.200 --> 02:00.200 They determine what UTC currently is. 02:01.200 --> 02:06.200 And if you think about that a little bit more, it might get a little bit existential dread, 02:06.200 --> 02:10.200 because once time is gone, you can't measure it anymore. 02:10.200 --> 02:16.200 So if all of those machines get broken, do we suddenly lose our meaning of time and get 02:16.200 --> 02:18.200 very scary? 02:18.200 --> 02:26.200 Anyway, so you have this UTC time, but it's on those devices. 02:26.200 --> 02:40.200 You want to get them to your local computer, your local clock, your mobile phone, all kinds of stuff. 02:40.200 --> 02:42.200 So how would you do that? 02:42.200 --> 02:48.200 Of course, I could just look at the clocks on the displays on them and just take my clock to them 02:48.200 --> 02:52.200 and just sort of align and yeah, that's fine. 02:52.200 --> 02:55.200 But that doesn't really scale very well. 02:55.200 --> 03:05.200 So for the internet, we have the network time protocol, which is able to synchronize this time over the internet. 03:05.200 --> 03:08.200 There's a bit of a problem though. 03:08.200 --> 03:13.200 Network, the network time protocol is completely unprotected, 03:13.200 --> 03:16.200 and can be spoofed absolutely, truly. 03:16.200 --> 03:20.200 In fact, all the versions of the protocol didn't have, 03:20.200 --> 03:22.200 or almost didn't have any random bytes at all. 03:22.200 --> 03:28.200 So even off-path attackers could truly sort of predict when the next request would be, 03:28.200 --> 03:34.200 and then jump in a little response for that request with their own timestamp, 03:34.200 --> 03:38.200 and especially in the olden days, clients would then be like, 03:38.200 --> 03:42.200 well, that's probably the time then, because that's a response to my request. 03:42.200 --> 03:48.200 So why do we even care if time is synchronized? 03:49.200 --> 03:55.200 There's lots of reasons, but for the reasons of this talk, 03:55.200 --> 03:59.200 we're mostly talking about security, the security domain. 03:59.200 --> 04:04.200 Specifically, TLS connections for setting up a TLS connection, 04:04.200 --> 04:05.200 you need to have a certificate. 04:05.200 --> 04:10.200 A certificate has a beginning and an end for a period when it's valid. 04:10.200 --> 04:14.200 Outside of those times, it's not valid, so it shouldn't be accepted, 04:14.200 --> 04:16.200 and it doesn't get accepted. 04:16.200 --> 04:20.200 But if you don't know the time, you don't know when that period starts and ends. 04:20.200 --> 04:22.200 The same for, for example, to you, to P tokens. 04:22.200 --> 04:26.200 If you're clock us off by a minute, good luck getting a proper to you to P token, 04:26.200 --> 04:30.200 because they are only valid for a minute, generally. 04:30.200 --> 04:35.200 And there's lots of other stuff, basically, the thing here is, 04:35.200 --> 04:40.200 the whole world depends on you to see almost everywhere. 04:40.200 --> 04:45.200 From cellular networks to audio and video synchronization, 04:45.200 --> 04:49.200 streaming, you name it, it will use the time somewhere. 04:49.200 --> 04:53.200 So actually getting the time to devices is actually quite important. 04:53.200 --> 04:58.200 And let alone just that you want to be on time for your appointments, et cetera. 04:58.200 --> 05:02.200 So yeah, it's used a lot. 05:02.200 --> 05:08.200 And yet, even though it, that time is essential for all these security protocols, 05:08.200 --> 05:12.200 it depends on a fundamentally broken protocol, 05:12.200 --> 05:17.200 a protocol that fundamentally is insecure. 05:17.200 --> 05:22.200 And maybe some of you are like, oh shit. 05:22.200 --> 05:25.200 But luckily, there is a solution. 05:25.200 --> 05:28.200 It's called network time security. 05:28.200 --> 05:33.200 It's been standardized since September of 2020. 05:33.200 --> 05:39.200 And it adds a little additional step called the key exchange phase. 05:39.200 --> 05:41.200 That's based on TLS. 05:41.200 --> 05:44.200 And some of you might now be thinking, hold on. 05:44.200 --> 05:47.200 Didn't you just say that time was needed for TLS. 05:47.200 --> 05:51.200 And now TLS needs to hold on way the second. 05:51.200 --> 05:54.200 But okay, I know about that. 05:54.200 --> 05:57.200 Details skipped that for now. 05:57.200 --> 06:05.200 This key exchange protocol basically exchanges some secrets. 06:05.200 --> 06:07.200 It uses the TLS keys. 06:07.200 --> 06:12.200 It extracts the TLS keys and then uses that to add some additional dates on top of every 06:12.200 --> 06:13.200 NTP packet. 06:13.200 --> 06:19.200 Some extra extension fields is what they are called in NTP speak. 06:19.200 --> 06:24.200 And those packets that those actual details will ensure that the header above it, 06:24.200 --> 06:26.200 so the actual timestamps are actually secure. 06:26.200 --> 06:30.200 So they're not encrypted, but they are verified. 06:30.200 --> 06:32.200 Because I mean time is public. 06:32.200 --> 06:35.200 So who cares if it's encrypted or not. 06:35.200 --> 06:39.200 But at least we want to be sure that every time I send a request, 06:39.200 --> 06:44.200 the response comes from the party that I wanted it to come from. 06:44.200 --> 06:49.200 Unfortunately, however, again, back to shit. 06:49.200 --> 06:56.200 Almost every device in use today still uses NTP by default. 06:56.200 --> 06:57.200 I've tried looking. 06:57.200 --> 07:01.200 I can't find any SNTP, which is simple network time protocol, 07:01.200 --> 07:05.200 just uses a single time source instead of multiple time sources, 07:05.200 --> 07:09.200 which the regular NTP protocol is supposed to use. 07:09.200 --> 07:15.200 But most laptops most devices actually use the simple network time protocol. 07:15.200 --> 07:22.200 And unfortunately, I don't know if any that support NTS. 07:22.200 --> 07:26.200 So you can switch to a full NTP client with NTS support. 07:26.200 --> 07:31.200 So you could switch to NTP security or my personal favorite NTP RS. 07:31.200 --> 07:38.200 But I can sort of understand and we can understand that that may be not everyone is going 07:38.200 --> 07:45.200 to want to switch to one of these full clients, even though they're not really that heavy. 07:45.200 --> 07:54.200 So actually what we're also doing is implementing a network time security for system D, 07:54.200 --> 08:00.200 something D. So at least hopefully in the future everyone can benefit from this. 08:00.200 --> 08:08.200 We still need a little bit of help, so if anyone wants to help, the link is over there. 08:08.200 --> 08:12.200 So you have your NTP client. 08:12.200 --> 08:20.200 And typically, if you look at your configuration, that NTP client will points to pool.nTP.org. 08:20.200 --> 08:26.200 And this is a public pool of servers, some 5000 servers. 08:26.200 --> 08:30.200 And what it does is it looks at your IP address. 08:30.200 --> 08:36.200 And it automatically gives you a couple of servers via DNS that are relative, 08:36.200 --> 08:40.200 the close to you. That means that you get servers that are relatively effective. 08:40.200 --> 08:46.200 So you get relatively good time. 08:46.200 --> 08:56.200 But using that DNS system together with TLS, which requires a certificate for that domain, 08:56.200 --> 09:01.200 would mean that all of those 5000 servers would now all share the same certificate, 09:01.200 --> 09:07.200 or we would have to issue 5000 certificates valid at the same time for the same domain. 09:07.200 --> 09:15.200 That sounds like a security nightmare, because even one of those 5000 operators would have to 09:15.200 --> 09:19.200 leak their private key and all of a sudden security is gone again. 09:19.200 --> 09:23.200 So we need alternative approaches. 09:23.200 --> 09:27.200 Luckily, we have some alternative approaches. 09:27.200 --> 09:32.200 So we are currently looking at two approaches. 09:32.200 --> 09:36.200 The first one is called the key exchange load balancer. 09:36.200 --> 09:42.200 Basically, this is a proxy that terminates the TLS connection, 09:42.200 --> 09:50.200 and then forwards another TLS connection to the providing time server. 09:50.200 --> 09:55.200 There's a big advantage of this is that clients don't need to be modified. 09:55.200 --> 10:01.200 So they can any regular NTS client right now can just use this as is. 10:01.200 --> 10:04.200 They don't notice at all. 10:04.200 --> 10:11.200 servers do need modifications, but hopefully server maintainers are a little bit more enthusiastic about this stuff, 10:11.200 --> 10:14.200 so hopefully less problems there. 10:14.200 --> 10:22.200 Another big disadvantage here is that the load on the pull servers themselves will probably be significantly higher, 10:22.200 --> 10:29.200 because serving TLS connections is significantly harder than just doing DNS results. 10:29.200 --> 10:33.200 So that's the other alternative. 10:33.200 --> 10:39.200 We can still do DNS, just like with regular NTS people. 10:39.200 --> 10:45.200 But now we need client side modifications, because the client now will need to do an SRV lookup, 10:45.200 --> 10:50.200 and then get a specific domain name for a specific server, and then needs to go to that server, 10:50.200 --> 10:56.200 and do the whole key exchange, and to be continuing them. 10:56.200 --> 11:02.200 So we need client side modifications, so existing NTSP clients would not be compatible with this. 11:02.200 --> 11:07.200 But the advantage is now that we don't need any more server side modifications. 11:07.200 --> 11:15.200 The other big thing that we're worried about is that we now need to verify that these SRV records are actually from the pull, 11:15.200 --> 11:20.200 and not from some other party, because DNS itself is also not encrypted. 11:20.200 --> 11:28.200 So you run into the same issue as with these timestamps from SP packets. 11:28.200 --> 11:35.200 So we need to do the NSAC validation, and the NSAC validation is a whole thing in itself. 11:35.200 --> 11:40.200 So you could do the NSAC validation on a resolver, and then use the NSO for HTTPS, 11:40.200 --> 11:49.200 but then you run again into the TLS, depends on time, depends on TLS, depends on time stuff, issues. 11:49.200 --> 11:53.200 Basically, we're implementing these two methods right now. 11:53.200 --> 12:02.200 And if anyone wants to do that, please join this, help us get this working. 12:02.200 --> 12:09.200 Right now we're on the, especially experimental domain name, experimental.ntspooltest.org. 12:09.200 --> 12:14.200 Hopefully that makes it clear that this is definitely experimental. 12:15.200 --> 12:25.200 So we will move the main once we're sure that this runs a little bit more stable, but right now we just want more clients, more servers to join this, especially clients, by the way. 12:25.200 --> 12:32.200 So if you have your personal laptop, and you don't mind everyone's involved checking your phone, if the laptop time is still correct, 12:32.200 --> 12:37.200 then please join your laptop to this, or maybe like a little home server or something. 12:37.200 --> 12:41.200 If you can, that would be very nice. 12:41.200 --> 12:48.200 Eventually, we would like these two methods to become ITF standards as well, so everyone else will implement them as well. 12:48.200 --> 12:53.200 But for now, we do have patches for all the major implementations, so Croni and TPCC. 12:53.200 --> 12:58.200 And of course, my personal favorite NTSPDRS. 12:58.200 --> 13:06.200 So please join us in getting NTS everywhere and hopefully making the internet a little bit more secure. 13:06.200 --> 13:14.200 Thank you. 13:14.200 --> 13:24.200 Any questions from the audience? 13:24.200 --> 13:31.200 I was almost afraid the message was too clear. 13:31.200 --> 13:46.200 I was wondering, in addition to the two approaches you described, have you also considered a cryptographic solution, such as cross-signing the certificates with a known intermediary from the pool that an all the implementations could trust? 13:46.200 --> 13:59.200 Yes, so the issue with using TLS is that all, so you have pool.ntp.org is your domain name, so you would need to have a certificate that is valid for pool.ntp.org. 13:59.200 --> 14:08.200 And once you have a certificate that is valid for pool.ntp.org, that means that if you leak the private key or whatever, the certificate for that, 14:08.200 --> 14:11.200 then someone else can act as if they are part of the pool. 14:11.200 --> 14:20.200 So if you have 5,000 operators, then we need to check that 5,000 operators are all doing this correctly, and none of them is making a mistaken. 14:20.200 --> 14:29.200 So that sort of the worry here is that once you get more and more server operators, and these server operators are not part of the organization of the pool themselves. 14:29.200 --> 14:31.200 They are independent parties. 14:32.200 --> 14:48.200 So if you have 5,000 parties that are independently all having access to that same certificate or at least a certificate valid for that domain, that just means that like the chances of someone leaking a certificate is just too high. 14:48.200 --> 14:58.200 So this might be a loaded question, but you reference Crony and NTPs Act, but what about plain old NTPD, the reference implementation? 14:58.200 --> 15:17.200 I have lots of opinions about NTPD, but actually one of them is that NTPD doesn't support NTS, and it hasn't supported it since it's certification or it's standardization since 2020. 15:17.200 --> 15:27.200 Yeah, that's basically everything factual I can say about it. I have lots of more opinions about it, but I want to voice them here. 15:27.200 --> 15:42.200 I would also consider it not to be a reference implementation, by the way, because the reference is the NTPIDF standard and not like their specific implementation. 15:42.200 --> 15:44.200 Let's thank the speaker again.