Bas, my post was not about making the pool support NTS. If you are not interested in this NTS topic, feel free not to write to this topic. If it helps you, see the “Tracking” button at the bottom of this topic and select “Muted”. This way you will not be seeing how others are possibly implementing NTS on their server.
2 Likes
sorry if this has been covered before.
I’m not up-to-date on network topology or naming conventions, or nts, but why did nts settle on symmetric keys? That requires key exchange mechanisms. Because of the nature of symmetric keys, if the key exchange is compromised, then we are back to square 1, someone can use that client’s key to spoof a time message.
Why not asymmetric public/private keys like https?
Why encrypt and not just sign the packet?
That would have meant that clients that doesn’t care about the validity of the packet doesn’t verify the signature. Clients that do care about the signature can pull the ssl certificate from the server and verify the signature.
It does support asymmetric keys just like https. (It may still support symmetric I think, but is not using it by default)
NTS is not encrypting every packet, just signing it. True time is public and does not need encryption. Also by not encrypting, UDP can still used for low latency and less bandwidth. Signing ensures the packets are not tampered with, and come from the correct domain.
1 Like
Why? Why should people interested in NTS stop discussing NTS?
Yes, we will, don’t worry.
Sure, well-known by now, and I don’t think anybody has any issue whatsoever with your view. They might not agree with it, but they accept it.
Similarly, please accept that other people have different views on NTS, and would like to discuss the topic amongst themselves. And stop butting in, not useful at all.
This is like the IPv6 topic all over again…
2 Likes
Indeed, it uses the same TLS mechanisms as HTTPS. In both cases, the asymmetric cryptography is used for deriving/agreeing symmetric keys during the TLS/NTS handshake, which are then used for the protection of the NTP packets.
Asymmetric cryptography is much heavier on resources than symmetric cryptography, so the former is used sparingly, i.e., mostly to secure agreement of symmetric keys. And for all the bulk processing, e.g., encryption in case of HTTPS, symmetric cryptography is used, using the keys agreed under protection of asymmetric cryptography.
2 Likes
Thanks for sharing! Happily enabled my instances in Finland and Sweden to use your server as an additional trusted time source.
Pretty much all of my servers are offering NTS as well, but I am currently only using that among my own servers/for my own clients, the service is currently not published anywhere.
1 Like
You haven’t understood how a man-in-the-middle attack works. I don’t need to send or resend anything and the protocol doesn’t matter.
Let’s say I found a backdoor into my ISPs main router. I just filter for UDP/123 and and always set the most significant bits in the receive and transmit timestamp (around bit 256 and 320 of every packet), not much processing power required. It’s almost the same every NAT router does, recognize some packet types and replace some bit pattern with e.g. your public IP.
Suddenly all clients of my ISP see the wrong time, no matter which NTP server they use, stratum 1 of the national laboratory or the pool. All time they receive will be near 2036 because every cleartext NTP packet will be manipulated without the chance of detection.
I don’t care that monitors outside my network perhaps detect all servers hosted within my ISP as false-tickers because I was careless and manipulated packets in both directions. It’s perhaps a nice denial of service if perhaps 10% of the servers of a zone a suddenly removed from the pool.
To fix that you (as a customer behind my manipulated ISP) could fetch time with NTS over the internet. Then your server would disregard all the manipulated packets because the cryptographic checksum is invalid. So worst case with no other time source like GPS, longwave timestation, mobile phone network… you would enter hold-over mode but not time warp into the future.
1 Like
Yeah I know the draft 
If you think the hurdle is low to trust someone with a working email, look at “Let’s encrypt”…No email required, just be reachable under your chosen DNS name.
The purpose of pool NTS and the whole “every website must be encrypted” is just to have the assurance that all data you receive isn’t manipulated by MitM attacks, malware on your device or spoofed.
Even the PTB, Germany’s metrological institute provides their website and stratum 1 time fresh of the cesium fountain with just domain validated certificates of Let’s encrypt 
No fancy extended validation certificates with the green org name (I know already dead in browers, but for years a cash cow for certificate providers)
1 Like
A lot of these arguments closely mirror the debate about “https everywhere” — it’s too expensive, it’s too hard to deploy, it’s misguided to do it except for systems that really need it such as those that deal with financial transactions, etc.
For HTTPS, those arguments were at one time absolutely valid, but by today they are much less so and it’s now widely accepted to put almost every web site behind HTTPS even when it has no login functionality.
We only got from the first state to the second because of people working to make the hardware and software infrastructure ready for that. It needed both faster hardware and simple deployment through Let’s Encrypt and clones.
The fact is that you can’t trust stuff coming in from the network so in increasingly many scenarios we layer crypto. For a long time that’s still too hard and expensive for a trivial use case like NTP but the cost of doing it will keep going down, meanwhile the cost of the alternate means of securing it — having on-site stratum 0 clock — will not decrease anywhere near as fast.
At some point the crossover is reached where it is just trivial to enable this in software (like how people deploy an HTTPS site today) and if you instead told a person, no, you should instead buy extra physical hardware and run wires to a window or roof space… well, good luck with that. I get that doing so is a beloved pastime for many here, but (a) that’s not being taken away from anyone, and (b) that’s not the same as the number of people who just want to stand up some time servers for their org.
So my conclusion is that people will continue to work on making NTS deployable while taking flak from the sidelines, and then all of a sudden one day (perhaps years from now), it will be in widespread use, partly because of those people’s efforts.
2 Likes
Login functionality is not the only use case where HTTPS makes sense. Some WLAN hotspots, e.g., in hotels, have been known to inject additional stuff into web pages accessed via plain HTTP, which is annoying at best, but can lead to more serious issues in worse cases.
Even with on-site stratum 0, depending on requirements, one might even want to add NTS between stratum 1 servers and clients, or secondary servers, which are all “local” (e.g., in the same network, in same administrative domain, in the same data center,…). YMMV.
Seen that too.
Have been playing with NTS yesterday to understand what happens if you ask NTS but it’s not there.
Then you get no time at all and the server is ignored.
That makes me wonder how Ubuntu is going to do it, as the pool doesn’t support it.
Do they make their own pool? Did they make a deal with the super-large-time-servers?
Anybody know?
1 Like
I was expecting a responselike this. Did you read my post regarding the number of ntp replies my ntp appliance can handle vs the number of nts replies it can handle? The extra load is not insignificant.
Yes the whole internet is now https, and how many servers does that entail? The load of the whole https internet is spread over millions of servers, whereas the ntp pool consists of a few thousand servers, some running on raspberry pis. Telling everyone to upgrade to https hardware capable of a few thousand requests per second will kill the pool.
Ps: there are some companies’ websites that fall over when they get a few thousand requests per second. No?
I’m NOT against nts, just not very pro nts, maybe because my professional ntp server can only do 500 requests per second? 
If you’re sorry to say it, then don’t. There are more appropriate words to express your opinion.
1 Like
Interesting, wheres the post?
He did here, few posts up, I believe it’s post 18.
Did you read the article?
The security model is different. With Let’s encrypt, you need to prove that you control the domain name to get a certificate for it issued to you, and the certificate then “proves” to others that when they access the site at the domain name, it really is the site at that domain name controlled by who the certificate was issued to. And they need means outside the PKI to learn the name of your service, and how they establish that they can trust the name.
With the PTB (or NetNod in Sweden, or Cloudflare, or time.nl, or BEV in Austria), through the chain of trust established, the certificate you verify when you access those services proves (within the constraints of how the public key infrastructure and CA systems work and are operated, including that most people implicitly trust those certificate authorities that your OS has selected on your behalf and thus ships with) that you are actually accessing the time server under the name you entered, and not some other. Provided you in turn obtained the name of the server you want to access through some means that you consider trustworthy, i.e., you believe that the service behind ptbtime1.ptb.de is really operated by the PTB. And for those “big” sites (consider banks, Google, Amazon, …), more/stricter verification is typically required by the issuing CA than what Let’s encrypt requires.
With the pool, this is slightly different, as it does not verify that the server operator controls the domain (as it does not, the pool does), or has other “strong” means of verifying the link between the domain name, and an individual server. Owning an anonymous e-mail address totally independent of the pool’s domain names is sufficient. To me, that does not provide sufficient trustworthiness to warrant the effort of setting up such a complex system.
The only thing it does is goto your domainname, check the HTTP(S)-server access and gives the certificate.
Other then that it checks nothing.
I got refused yesterday as my Apache runs on my server on port 90, not 80.
80 is redirected.
On my other severs the certificate is granted as Apache runs port 80.
It doesn’t check anything else. After that your website runs as trusted HTTPS.