On Apr 29, 2016, at 4:43 PM, Roger Marquis <marq...@roble.com> wrote: >>> What are the reasons FreeBSD has not deprecated ntpd in favor of >>> openntpd? >> >> While I cannot speak for anyone other than myself, the two simply aren't >> equivalent. As a conscious design choice, OpenNTPD trades off accuracy >> for code simplicity. > > IIRC openntpd is accurate down to ~100ms.
Hopefully better, since that is terrible clock accuracy. > Ntpd does have a lot of code dedicated to additional accuracy but this is > exactly the security trade-off I want to avoid. Most of the ntpd security bugs relate to authentication, in part because almost nobody ever used it. The timing code is more robust. > Who needs millisecond accuracy anyway? Cell phones, cell phone towers, computers handling financial transactions, etc. >> It lacks support for NTP authentication, > > This is still the case but considering the tiny fraction of ntpd sites > that use encryption and the fact that encryption is not enabled by > default it is not really relevant to FreeBSD. I'll give you this-- ntp auth is unlikely to be missed by most people. >> access controls, reference clocks, multicast/broadcast operation, > > Several reflection vulnerabilities over the past few years have been due > to holes in ntpd's access control so its hard to appreciate their value > or the value of these other little used features. Any listening network service can be used for reflection attacks. >> or any kind of monitoring/reporting. > > This is no longer correct. Openntpd's 'ntpctl' reports are sufficient > for the vast majority of sites. Surely individual sites can make up their own minds about that, right? >> OpenNTPD is probably closer to rdate than ntpd in terms of their relative >> capabilities. > > Rdate? Really? This is a little over the top don't you think? Not really. Lack of reference clocks is a big deal, and so is SNTP vs NTP. >> I'd rather we keep ntpd in base as a consequence. > > I'm sure the NSA would like it if we all did, considering the order of > magnitude difference in security vulnerabilities and the fact that the > daemon has to run as root. Most time daemons need root in order to execute adjtime() / adjtimex() / ntp_adjtime(). Systems with a capability model might use something like CAP_SYS_TIME instead; if present, ntpd can be run without root-- see NetBSD, Solaris, and some Linux flavors. >> The only change I'd suggest would be to alter the default configuration >> such that all unauthorized access were blocked (i.e., set "restrict default >> ignore" and "restrict -6 default ignore"). > > This is a good idea, perhaps, for those sites that need to run ntpd for > one of the reasons listed above but again, that's a tiny fraction of the > installed base. Most FreeBSD systems only need to query a timehost, not > to be a time server. Your data for that? > One of ntpd's biggest disadvantages is that its udp socket cannot be > disabled i.e., it cannot be configured as just a client (though you can > use ipfw or pf to that effect). Considering the demand for this feature > you have to ask why ntpd hasn't been able to implement it? It's not possible to perform NTP timestamp exchange properly without both sides listening because you want to determine both the round-trip delay and the clock offset. openntpd implements SNTPv4 and not the NTPv4 protocol. The extra sanity checking in the latter helps detect and mitigate against falsetickers, which is why folks continue to use NTP and ntpd rather than rdate or SNTP implementations like openntpd. Regards, -- -Chuck _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"