Internally, OpenNTPD does not maintain millisecond accuracy and can vary 50-200ms from “real” time because it omits a variety of algorithms that increase accuracy in favour of code simplicity. The OpenNTPD project acknowledged the criticism, but stated that the lack of microsecond precision was a design tradeoff that benefited simplicity and security.
That’s rather unfortunate, did anything improve there?
If sub millisecond accuracy is what you need from your network time protocol daemon then OpenNTPD is not the tool you need.
However if you want to reduce the attack surface of your systems, and specifically your NTP daemon, then OpenNTPD is a great tool for keeping your network time sync’d.
That post also shows that the problem was not a technical one.
There’s a cultural rift between the OpenBSD community and the NTP community.
They have different priorities and could not reconcile them.
The greatest technical solution is always possible in theory, but to make it happen
you need the right combination of people to work together in a constructive fashion.
OpenNTPD is good enough for Theo and Henning, and that’s who this software
was written by and for. It was obviously not written by and for people who keep atomic
clocks at home. If you want something different, try to contribute to OpenNTPD
to change it, or write your own.
Sub-millisecond accuracy comes with orders of magnitude increased complexity. This means both more code and much more complex code which is a larger attack vector and harder to audit.
The doas utility is much less capable than sudo. If you need PAM support, complex group policies synchronized across multiple systems and much more than surely you need sudo - if you only need to safely elevate privileges on your laptop then why would you want the baggage and complexity those features bring?
Sub-millisecond accuracy comes with orders of magnitude increased complexity. This means both more code and much more complex code which is a larger attack vector and harder to audit.
There is no truth to this statement. Talk to phk if you want details or just look at his ntimed code which refutes this.
See, the problem with analogies is they are superficial to the point of being pointless. We are not talking about privilege management, but about networked timekeeping. Since NTP servers run in a hierarchy of stratums, any imprecision introduced in the tree is passed down. Sure it’ll be often drowned out by network latency variations but overall the erosion of accuracy is not helping.
As far as I know, none of the people who care about real time submitted a patch to improve things. So it’s hard to judge. Such a small, easy diff, but nobody cares to make it. :(
So you suggest the authors are unable (due to lack of skills/time) to make a proper implementation of NTP server, and the expectation is it should be fixed by a patch from the woods? Fair enough, I have my share of half-baked projects too (although don’t really expect anyone to fix things up for me).
But perhaps promoting it for mainstream use is premature then.
Not exactly. I’ve been using openntpd for a while and have not yet suffered any (known) grievous harm. I look at the magnitude of concern some people have for openntpds inadequacies, the ease with which it’s promised that things can be done correctly, and things don’t quite add up. The problem is either less severe or more difficult to fix than claimed.
From Wikipedia:
That’s rather unfortunate, did anything improve there?
[Comment removed by author]
Thank you for the straightforward and informative answer. The criticism in Wikipedia then appears to no longer hold.
[Comment removed by author]
If sub millisecond accuracy is what you need from your network time protocol daemon then OpenNTPD is not the tool you need.
However if you want to reduce the attack surface of your systems, and specifically your NTP daemon, then OpenNTPD is a great tool for keeping your network time sync’d.
This basically says that secure applications and precise timekeeping are incompatible, which intuitively I don’t expect to be true.
EDIT: sorry if that sounds arrogant, I know that intuitions are often wrong, but that does sound bizarre.
It was decided that the benefit of more precise timekeeping was not worth the extra complexity that it would entail.
Hopefully this reply on the tech@openbsd.org mailing list will help shed some light on some of the issues.
You are right it could be more accurate and still be secure - but someone has to contribute that code.
That post also shows that the problem was not a technical one. There’s a cultural rift between the OpenBSD community and the NTP community. They have different priorities and could not reconcile them. The greatest technical solution is always possible in theory, but to make it happen you need the right combination of people to work together in a constructive fashion.
OpenNTPD is good enough for Theo and Henning, and that’s who this software was written by and for. It was obviously not written by and for people who keep atomic clocks at home. If you want something different, try to contribute to OpenNTPD to change it, or write your own.
Sub-millisecond accuracy comes with orders of magnitude increased complexity. This means both more code and much more complex code which is a larger attack vector and harder to audit.
The
doasutility is much less capable thansudo. If you need PAM support, complex group policies synchronized across multiple systems and much more than surely you need sudo - if you only need to safely elevate privileges on your laptop then why would you want the baggage and complexity those features bring?There is no truth to this statement. Talk to phk if you want details or just look at his ntimed code which refutes this.
But who uses ntimed?
I’m very interested in ntimed. I see https://nwtime.org/projects/ntimed/ has been updated somewhat recently and claims preview releases are possible for 2017, but the git repo at https://github.com/bsdphk/Ntimed shows no activity in the last 2.5 years.
See, the problem with analogies is they are superficial to the point of being pointless. We are not talking about privilege management, but about networked timekeeping. Since NTP servers run in a hierarchy of stratums, any imprecision introduced in the tree is passed down. Sure it’ll be often drowned out by network latency variations but overall the erosion of accuracy is not helping.
As far as I know, none of the people who care about real time submitted a patch to improve things. So it’s hard to judge. Such a small, easy diff, but nobody cares to make it. :(
So you suggest the authors are unable (due to lack of skills/time) to make a proper implementation of NTP server, and the expectation is it should be fixed by a patch from the woods? Fair enough, I have my share of half-baked projects too (although don’t really expect anyone to fix things up for me).
But perhaps promoting it for mainstream use is premature then.
Not exactly. I’ve been using openntpd for a while and have not yet suffered any (known) grievous harm. I look at the magnitude of concern some people have for openntpds inadequacies, the ease with which it’s promised that things can be done correctly, and things don’t quite add up. The problem is either less severe or more difficult to fix than claimed.