So, hi everyone.
So my name is Ruben, last name Neville for anyone Dutch.
So I work at the Traffected Tech Foundation, which is a Dutch non-profit organization.
We do most of our work on open infrastructure software for the internet.
My own focus is on time synchronization software, which is NTP clients and server, and
step-time, which is our PTP library, and at least for now, our PTP Linux server and clients.
But today I want to talk to you about our NTS pool project.
And before I do that, I just see a show of hands, who here would be able to tell the
current time right now.
Anyone?
Yeah.
Some people are not so sure anymore, since I asked the question.
Let me quickly go over what I was looking for.
What I was looking for actually was time in UTC.
UTC is the worldwide standard.
All countries in the world use UTC for time.
And actually on the slide, there's a picture here of three boxes.
Those are three atomic clocks.
There are about two kilometers that way.
They are the Belgian servers for determining UTC.
In total, there are some 400 of these boxes and all of them together.
They determine what UTC currently is.
And if you think about that a little bit more, it might get a little bit existential dread,
because once time is gone, you can't measure it anymore.
So if all of those machines get broken, do we suddenly lose our meaning of time and get
very scary?
Anyway, so you have this UTC time, but it's on those devices.
You want to get them to your local computer, your local clock, your mobile phone, all kinds of stuff.
So how would you do that?
Of course, I could just look at the clocks on the displays on them and just take my clock to them
and just sort of align and yeah, that's fine.
But that doesn't really scale very well.
So for the internet, we have the network time protocol, which is able to synchronize this time over the internet.
There's a bit of a problem though.
Network, the network time protocol is completely unprotected,
and can be spoofed absolutely, truly.
In fact, all the versions of the protocol didn't have,
or almost didn't have any random bytes at all.
So even off-path attackers could truly sort of predict when the next request would be,
and then jump in a little response for that request with their own timestamp,
and especially in the olden days, clients would then be like,
well, that's probably the time then, because that's a response to my request.
So why do we even care if time is synchronized?
There's lots of reasons, but for the reasons of this talk,
we're mostly talking about security, the security domain.
Specifically, TLS connections for setting up a TLS connection,
you need to have a certificate.
A certificate has a beginning and an end for a period when it's valid.
Outside of those times, it's not valid, so it shouldn't be accepted,
and it doesn't get accepted.
But if you don't know the time, you don't know when that period starts and ends.
The same for, for example, to you, to P tokens.
If you're clock us off by a minute, good luck getting a proper to you to P token,
because they are only valid for a minute, generally.
And there's lots of other stuff, basically, the thing here is,
the whole world depends on you to see almost everywhere.
From cellular networks to audio and video synchronization,
streaming, you name it, it will use the time somewhere.
So actually getting the time to devices is actually quite important.
And let alone just that you want to be on time for your appointments, et cetera.
So yeah, it's used a lot.
And yet, even though it, that time is essential for all these security protocols,
it depends on a fundamentally broken protocol,
a protocol that fundamentally is insecure.
And maybe some of you are like, oh shit.
But luckily, there is a solution.
It's called network time security.
It's been standardized since September of 2020.
And it adds a little additional step called the key exchange phase.
That's based on TLS.
And some of you might now be thinking, hold on.
Didn't you just say that time was needed for TLS.
And now TLS needs to hold on way the second.
But okay, I know about that.
Details skipped that for now.
This key exchange protocol basically exchanges some secrets.
It uses the TLS keys.
It extracts the TLS keys and then uses that to add some additional dates on top of every
NTP packet.
Some extra extension fields is what they are called in NTP speak.
And those packets that those actual details will ensure that the header above it,
so the actual timestamps are actually secure.
So they're not encrypted, but they are verified.
Because I mean time is public.
So who cares if it's encrypted or not.
But at least we want to be sure that every time I send a request,
the response comes from the party that I wanted it to come from.
Unfortunately, however, again, back to shit.
Almost every device in use today still uses NTP by default.
I've tried looking.
I can't find any SNTP, which is simple network time protocol,
just uses a single time source instead of multiple time sources,
which the regular NTP protocol is supposed to use.
But most laptops most devices actually use the simple network time protocol.
And unfortunately, I don't know if any that support NTS.
So you can switch to a full NTP client with NTS support.
So you could switch to NTP security or my personal favorite NTP RS.
But I can sort of understand and we can understand that that may be not everyone is going
to want to switch to one of these full clients, even though they're not really that heavy.
So actually what we're also doing is implementing a network time security for system D,
something D. So at least hopefully in the future everyone can benefit from this.
We still need a little bit of help, so if anyone wants to help, the link is over there.
So you have your NTP client.
And typically, if you look at your configuration, that NTP client will points to pool.nTP.org.
And this is a public pool of servers, some 5000 servers.
And what it does is it looks at your IP address.
And it automatically gives you a couple of servers via DNS that are relative,
the close to you. That means that you get servers that are relatively effective.
So you get relatively good time.
But using that DNS system together with TLS, which requires a certificate for that domain,
would mean that all of those 5000 servers would now all share the same certificate,
or we would have to issue 5000 certificates valid at the same time for the same domain.
That sounds like a security nightmare, because even one of those 5000 operators would have to
leak their private key and all of a sudden security is gone again.
So we need alternative approaches.
Luckily, we have some alternative approaches.
So we are currently looking at two approaches.
The first one is called the key exchange load balancer.
Basically, this is a proxy that terminates the TLS connection,
and then forwards another TLS connection to the providing time server.
There's a big advantage of this is that clients don't need to be modified.
So they can any regular NTS client right now can just use this as is.
They don't notice at all.
servers do need modifications, but hopefully server maintainers are a little bit more enthusiastic about this stuff,
so hopefully less problems there.
Another big disadvantage here is that the load on the pull servers themselves will probably be significantly higher,
because serving TLS connections is significantly harder than just doing DNS results.
So that's the other alternative.
We can still do DNS, just like with regular NTS people.
But now we need client side modifications, because the client now will need to do an SRV lookup,
and then get a specific domain name for a specific server, and then needs to go to that server,
and do the whole key exchange, and to be continuing them.
So we need client side modifications, so existing NTSP clients would not be compatible with this.
But the advantage is now that we don't need any more server side modifications.
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,
and not from some other party, because DNS itself is also not encrypted.
So you run into the same issue as with these timestamps from SP packets.
So we need to do the NSAC validation, and the NSAC validation is a whole thing in itself.
So you could do the NSAC validation on a resolver, and then use the NSO for HTTPS,
but then you run again into the TLS, depends on time, depends on TLS, depends on time stuff, issues.
Basically, we're implementing these two methods right now.
And if anyone wants to do that, please join this, help us get this working.
Right now we're on the, especially experimental domain name, experimental.ntspooltest.org.
Hopefully that makes it clear that this is definitely experimental.
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.
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,
then please join your laptop to this, or maybe like a little home server or something.
If you can, that would be very nice.
Eventually, we would like these two methods to become ITF standards as well, so everyone else will implement them as well.
But for now, we do have patches for all the major implementations, so Croni and TPCC.
And of course, my personal favorite NTSPDRS.
So please join us in getting NTS everywhere and hopefully making the internet a little bit more secure.
Thank you.
Any questions from the audience?
I was almost afraid the message was too clear.
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?
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.
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,
then someone else can act as if they are part of the pool.
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.
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.
They are independent parties.
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.
So this might be a loaded question, but you reference Crony and NTPs Act, but what about plain old NTPD, the reference implementation?
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.
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.
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.
Let's thank the speaker again.