Boffins want to stop Network Time Protocol's time-travelling exploits

Time NTP was upgraded(See what I did there!)

To be honest its about time NTP was replaced with something a bit more fit for purpose. Every month we have a issue with NTP due to mis-configuration or lack of understanding

Any new algorithm should include a modern security infrastructure using certificates to verify time sources, provide greater accuracy in LAN environments by piggy backing on IEEE 1558, more control on the skewing, improved configuration tool and better monitoring interfaces.

And you need a powerful computer to decrypt *any* encrypted/secure time source, NTP or any other proposal. There go precious milliseconds.

And if your ISP is anything like mine, latency sucks, so I'm happy if my computers are just showing the correct date !!!!

Consumer-grade 'puters

If you take a look at the time configuration in a typical consumer computer, you'll see one or two NTP servers nominated.

Erm, yes. A typical consumer computer is a consumer of NTP. It doesn't need nor expect atomic-clock accuracy. If it's within UDP-packet timeout time of its ISP's ntp server, that's plenty adequate. Or if it just polls time hourly, daily, or probably even weekly, that'll do.

Need more accuracy? Then you're not a consumer-grade 'puter. You want a competent sysop to configure your NTP with lots of peers, and no doubt other critical setup.

Methinks this is baked in. The protocol is the quintessential UDP user: better to lose a packet than to use a delayed packet! Configuration allows for different levels of operation: peer network, polling frequency, etc. Dammit, when I first set up NTP I used chrony not ntpd, precisely because of its advertised ability to deal with intermittent connections.

It sounds similar to peer to peer authentication where you establish trust which has been pushed as an alternative to PKI for embedded systems

Why not use a GPS dongle?

Any datacenter selling hosting services should have at least one server set up as a tier 1 GPS source with an actual GPS receiver.

Then the link(s) to the internet aren't vulnerable to interception/delay, and attackers would have to compromise the router (or whatever) connected to the GPS receiver.

A major datacenter could have three of them, ideally running three OSes (Cisco IOS, Linux, BSD) to make compromising two of them less likely, so this 'crowdsourcing' idea could work. Before anyone complains about how you might not be able to receive GPS inside the datacenter, they can run coax to an outside antenna.

NTP already implements auth...

I have to admit I'm not entirely sure what the problem is here; NTP already supports setting up basic symmetric keys to verify the connection with a remote NTP server. It's nothing special but it stops MITM timing attacks in their tracks. And if the server at the other end is compromised then you're hosed regardless of any authentication attempts.

https://access.redhat.com/solutions/393663

http://blog.ine.com/2007/12/28/how-does-ntp-authentication-work/

If your internal stuff is dependent on accurate time via NTP, then you should also have at least two internal clocks - as DougS points out it needn't break the bank, you can set up a Rapberry Pi with a GPS + PPS PiHat for less than £100 and that'll give you a "easily good enough" time source for millisecond accuracy (and for most businesses, second accuracy is perfectly good enough). Radio signal receivers are another relatively inexpensive option (and useful in a data centre where you might not be able to install an external GPS antenna). Install three or more and you can generally forego having to look outside your own network for NTP at all.

Bog-standard NTP and commercial clocks (which are usually just a linux box running some version of bog-standard NTP) should all support auth keys without issue (although TTBOMK windows' NTP implementation doesn't support it). Then you might want to think about using external NTP servers as tertiary sources - and again it's quite easy to fudge them to specify their stratum value as much worse than your internal ones, so even if evil haXx0rz perform timing attacks on a majority of your external tertiary servers your internal servers should still be following your internal clocks.

Call me cynical but wanting to implement a CA/PKI setup over the top of an NTP-ish protocol sounds a lot like another power grab by the people who want to set themselves up holding the keys in the same way that google seem to want to force everyone away from being able to use their own SSL certificates.

It's not an actual problem

I mean, yes, you can shift the time of servers around, in theory, if you put lots of effort into it and if the server operator doesn't have its own local NTP infrastructure, but in reality that's just a lot of hassle for little profit.

Clients typically don't care about NTP at all and only implement it's braindead cousin SNTP which gives you a very rough approximation of the actual time and date.

GPS sounds like a good idea, until you are inside, however for mobile devices, which have GPS anyhow, this is a sensible way to get a rather decent precision of time.

In some places, like Europe you have the additional possibility of getting your time via longwave transmitters. The DCF77 signal, carries the time in a way you can get your error well down below a millisecond. Other simmilar transmitters will still get you the time to a fraction of a second.