For NTS the server must have an valid tls-certificate so random a or aaaa records doesn’t fit into it. Otherwise NTP Pool have to create for every joining server a ssl-certificate and would get to a certificate authority. I don’t think that this would be practical and can’t scale. If we want a secure and stable system for NTP Pool, I think srv dns records could fit into the system. Every Server is responsible to have a valid ssl-certificate. The pool can check if the server has a valid certificate and integrate it into the pool of server which are randomized for response in the srv records.
At the moment ntpsec or ntpd don’t support dns srv records for pool. But a lot of configuration management systems(ansible, chef, puppet) can resolve the dns srv record and write through a template some server records to the ntpsec configs. Of course would it be very cool if ntpsec could integrate dns srv records as pool source.
I don’t foresee the ntp pool trying to implement it as it would add a lot more complexity and likely only end up with a miniscule amount of actual use. Most of the queries to the pool are SNTP, likely from embedded / mobile devices.
Even if the pool had NTS it still would likely not be allowed for any corporate requirement needing traceable / verifiable time sources.
I can understand if you want to wait until NTS is approved. But you could add SRV records for NTP so some clients could start to integrate the possiblity to discover ntp-server over dns-srv records. If NTS is approved and there is enough requests, you could easily extend your system to also support _ntske._tcp… as srv record and not only _ntp._udp…
NTS’ goal is to make a trusted authenticated association between a time client and a time server.
the NTP pool is a pool of anonymous suppliers of servers providing time distributed to clients on a random base through a pool of anonymous DNS servers with rotating records.
To me it seems that NTS and the NTP pool are at two different sides of the universe.
NTS can also help to prevent the system for some ddos attacks. Its totally okay for me if NTS isn’t implemented in the first step. The NTP Pool is in my opionion a service for service discovery and DNS SRV records are the definition how to make a service discover over DNS. So I think DNS SRV records fit perfectly into the system of NTP Pool.
I am not sure you get the purpose of the NTP pool right. It is not a service for service discovery. It is a system where volunteers can provide their server resources for free to others to obtain time. That’s it. If there would be a layer of authentication on top of it most volunteers would simply quit because they lack the knowledge to implement it.
Also, many servers would just cripple under the extra load of encrypted negotiation between the client and server. Many nodes are serving thousands of NTP requests per second. Imagine what happens if these all need NTS. The DNS servers are currently handing out addresses of NTP servers with TTL times in the order of a few minutes. That will cause a lot of new handshakes with every newly handed out IP address.
And with around 4000 server IPs in the field and hundreds of country and vendor level time domains, I am not sure how you want to implement the SRV records without creating a DNS zone with a huge amount of records. Serving these SRV records will slow down the central DNS servers too much.
My understanding of the ntppool was that it provides 3 Services:
Registration service for people who want to share their ntp-server with public
Monitoring of the ntp-server registered to check if they are alive
DNS-Loadbalance the DNS-Requests for diffrent regions and pools
3a. Limit the number of servers returned
3b. Randomize the order in the response
At the moment NTP pool only supports A or AAAA DNS-Requests for 3. My suggestion is also to provide SRV as valid DNS-Request. I don’t want to change the Loadbalance charakter of 3. So the response for a SRV-DNS-Request should answer with a limited set of servers and randomize the order of these.
I’d like to see the NTP pool to have some support for NTS. It couldn’t be compared to NTS servers provided by trusted companies, but I think it would still be good for preventing random MITM attacks on public wireless networks, etc.
I’m not sure if SRV records would be the best way to do that. Most NTP clients don’t support SRV records and it’s not trivial to implement. Wouldn’t the servers still have to have a certificate for a *.pool.ntp.org name? If it pointed to a different name, it would require DNSSEC to prevent MITM attackers from pointing to their servers, right?
A better option might be for the pool to periodically generate short-term certificates for the servers for an NTS specific zone (e.g. nts.pool.ntp.org). Most of my servers in the pool support NTS and I’d be happy to have them included in the zone.
To make it a bit more difficult for the attackers to get an NTS server in the pool there could be some restrictions, like you have to be a member of the pool for at least few years.
Why would anyone use Secure-NTP? It’s just a time-server.
NTS will and can not protect a system against hackers.
It’s just time send encrypted versus non-encrypted.
You can listen at it underway, but what is the point?
Spoofing will be hard as it uses a pool and the source-IP changes all the time.
If you want to protect yourself from possible-time-attacks, just use a GPS and don’t let it connect to the internet. Most safe way of timekeeping.
Also, NTP isn’t a continues thing, it polls a few times a day at best.
DDOS can not be stopped because it does NTS over NTP.
I fail to see the purpose as if it really needs to be that safe and secure, a simple GPS solves it in total.
Didn’t you notice the @littlejason99’s post date? At the time of writing, NTS was indeed a draft standard. And still it is somewhat infeasible for the current NTPPool infrastructure to implement NTS service.
Why? There is no point in using NTS at all.
NTP is serving time, nothing unsecure about it unless some nutters want to run different time then the rest of the world.
Time is time, no need to encrypt time…this is basically the most stupid idea to use encryption ever
There may be a situation where an evil man deliberately tries to break time through a MITM. Anything can happen in this situation:
end the validity of user account passwords;
end the validity of PGP certificates;
the two-factor authentication TOTP will not work;
backups outdated and the system will remove them;
it’ll break the DNSSEC.
Therefore, we are interested in reliable operation of time synchronization services. However, I thought that the best option would be to place your servers in the Yggdrasil mesh network, where network connections are always secure at the protocol level and there is no need to pile up additional security measures, including no need for certification authorities (a certification authority is a security point of failure, because it assures us of the reliability of the connection, but can be compromised).
NTP is not a secure protocol. However, as the pool servers are extremely diverse, for someone to conduct a MITM attack against you they will realistically need to be intercepting your specific internet connection. In any other scenario, your NTP client will simply ignore the server that’s giving bad time and continue to obtain accurate time from the others.
If an attacker sitting on your individual internet connection and trying to attack you via impersonating NTP servers is actually a realistic threat model for you, set the system time manually and turn NTP off. Your security needs probably outweigh the need for automatically setting your clock, and nothing you have listed requires a clock that is set so precisely that it would preclude manually setting it. A VPN of some kind is also likely a good idea.
Yggdrasil has nothing whatsoever to do with NTP, or the NTP pool. I am unsure why you are mentioning it here.
Thank you for this news. Right now, in some subnets, the provider (Beltelecom) is blocking NTP, redirecting requests only to servers controlled by it. I’m afraid you have to admit that the extreme variety of pool servers does not help in any way. I hope you are aware of some political problems with the Internet in Belarus.
The accuracy of the hardware clock is about ±1 seconds per day. After a month without NTP, you won’t even be able to browse the Internet in a browser, it will constantly point out errors in various TLS certificates of websites.
I will try to explain to you about Yggdrasil more simply. In fact, this is the same VPN that you recommended, only during last year’s Internet outage in the country, Yggdrasil worked, but the VPN did not. If there are NTP servers in Yggdrasil, then we will always have the exact time. In fact, there are already NTP servers in Yggdrasil, for example, 302:a2a5:dead:ded::a2a5. There are also NTS providers, for example, nts.netnod.se.
I just noted that it would be good if such a large pool as yours also thought about protecting the exact time. Not necessarily all servers, you can only part of them, for the experiment. Because sometimes, without protection, this time can be made completely inaccurate.
If you don’t understand something else, erayd, write to me, I will be happy to try to explain it to you.
By the way, here is a wonderful message editor, one of the most convenient that I use. Thanks.
This assertion is incorrect. A 30 second clock offset isn’t a problem for TLS; it does not care about clock synchronisation. As long as the current time appears to be within the certificate validity period, it will work.
Some higher level protocols do care about at least approximate clock matches. Of the things you listed, the most sensitive is TOTP authentication - but even that, as generally deployed, will happily tolerate a greater than 30-second offset. Even if you do run into clock-drift issues eventually, you can simply apply a manual correction to your clock, or NTP sync via a VPN, and the problem is resolved.
Yggdrasil is off-topic; you do not need to explain it here. You seem to be enthusiastic about it, but please note that it’s well beyond the scope of what the NTP pool does. I also have not recommended it to you previously - perhaps you are confusing me with somebody else?
The NTP pool does protect the correct time, via high diversity of servers. This is the most general and practical protection measure available to a large-scale NTP service, which the NTP pool is.
In the event that your ISP blocks access to pool servers - which it sounds like yours does - you are able to simply work around this by routing your NTP queries via a VPN that circumvents the block. That is the appropriate course of action here; trying to implement an additional protocol on the many thousands of pool servers is not realistically something that will happen.
