First, in the interests of disclosure: I'm one of the OpenSSH and OpenBSD developers, and the person responsible for the Portable branch of OpenNTPD. That said, the following is purely my own opinion.

I've decided to address some of the issues raised by Brad Knowles in an article entitled OpenNTPd Considered Harmful. While I think some of his points are valid (and some of those have been addressed since it was written), I disagree with others and some are quite misleading.

stratum and refid (ntptrace)
The comments about stratum and refid (the comment about ntptrace): these are valid points. They have been have been fixed for a while in the development tree and now in the openntpd 3.6.1 release.

Portability
I don't think the criticism about portability is warranted. At the time that article was written Portable OpenNTPD already supported Solaris (it was the 2nd target I did after Linux) and HP-UX support has since been added. I don't think it's valid to criticise a project that's only existed for a couple of months for "only" running on Linuxes, *BSD's, Mac OS X, and Solaris (which covers the 3 main *nix families in use today, Linux, BSD, System V). I suspect it's probably portable to any platform with a POSIX interface and an adjtime() syscall (or something that behaves like it) [update: and a good entropy source (such as /dev/random or a self-seeding OpenSSL)]; it already runs on every system that I have access that meets those criteria with the exception of one (and that one is for non-technical reasons).

Brad also says that the OpenNTPD developers "seem to be violently opposed to using certain methods which are known to be more portable, in favour of using techniques which are specific to OpenBSD". I'm not aware of what he's referring to here. There are several instances of changes in OpenBSD for the purposes of improving portability (eg 1, 2, 3) and if there are ways of doing things in -Portable to improve portability then I would be interested to hear them.

Finally, he describes the automated test procedures they use on the "flock of test/development machines we have at our disposal". Since the article was written I have added build and basic functionality tests for OpenNTPD to tinderbox automated tester that we also use for OpenSSH (the machines which appear will vary depending on which machines I have running at the time). BTW the key phrase here is at our disposal: we can't test on systems we don't have access to.

Split development
About the split OpenBSD/Portable development model, Brad says that it "pretty much guarantees that the two code bases will quickly diverge quite dramatically". This is not necessarily so: as a counterexample, OpenSSH has operated with this model for five years quite successfully. It requires discipline, but it can work. It is not a coincidence that OpenNTPD's portability layer looks like OpenSSH's.

In the case of OpenNTPD, the split between OpenBSD and Portable is quite clean and the differences in the common code are small, a total of approximately ~70 lines for 3.6.1p1 including man page diffs. (The diff is in the Portable tarball).

Clock disciplining
The comment about clock disciplining (compensation for systematic skew or drift) is a fair point, within limits. Right now OpenBSD doesn't permit changing of tickadj at the default securelevel so another mechanism is needed in the kernel. When this happens, ntpd will probably learn how to do it. (Note: this does not necessarily prevent it from being done on other platforms, for example see my experimental patch that adds crude skew compensation via adjtimex to Linux, which is implemented with zero changes to the common code.)

I would like to point out, though, that the charge of "jumping the clock forward or backward" is very misleading: at the time the article was written, OpenNTPD would never cause the clock to jump either forward or backward: the offsets are filtered (although the filters could be improved) and the adjustments were always done via adjtime (a "slew") which means the time is always monotonically increasing. Even now, the only time it will use settimeofday (a "step") for the first adjustment, and only if this behaviour is enabled with the -s option. In contrast, the reference implementation in its default configuration will step the clock any time the offset exceeds 128ms (see the ntpd man page, specifically the "-x" option).

Alternative server modes
Brad criticizes OpenNTPD for not imlementing broadcast, multicast and anycast modes because "the NTP protocol can put a heavy load on the server, and trying to handle thousands of clients, each in direct one-to-one communications, just isn't feasible".

Dr David Mills describes a Stratum-1 server running on a SPARC IPC (a 25MHz machine) serving 734 clients while using 1.54% of the CPU and concludes "that substantial numbers of clients with no significant degradation on other network services". Arithmetic suggests that even this long-obsolete machine could support thousands of clients.

While OpenNTPD doesn't support these modes now, it may in future, however it's not clear how much of a gain these would be in many environments. Broadcast mode is limited to the local network, thus it would only be necessary in environments where there are more clients in a single subnet or broadcast domain than can be handled by a single server. Multicast mode requires the network to support multicast routing (eg IGMP, DVMRP, MOSPF), although in an environment that supports it, it could result in a reduction of WAN traffic. Anycast mode is described in RFC 2030 as "provisional", and doesn't help with load, it only helps in locating a server, after which it operates in unicast mode.

Authentication and crypto
Regarding the comment about authentication and crypto: it depends on what your threat profile is. Brad correctly points out that it's not a zero-sum game. It is, however, a tradeoff: you're trading a reduction in risk that someone will be able to perform an active attack against your clock for an increased risk of a security issue in the additional code required to implement it. There's no way to prove the relative weights in this tradeoff, it's a matter of opinion.

As Brad points out, OpenNTPD's "cookies" always provides some protection against blind spoofing of responses. They're by no means perfect, but they're a simple measure that provides cheap insurance and requires no configuration or additional support in the server.

The symmetric-key authentication in NTP v3 seems to have limited deployment (probably due to key distribution issues and administrative overhead, and it appears that most public servers don't offer it) and is listed as optional in RFC 1305.

I can't comment much on the public-key modes in NTP v4 as at the time of writing the NTP v4 spec is not available, although from the description of the Autokey protocol it appears that it is based on X.509v3 certificates. I will only point out that OpenSSL's ASN.1 parser and X.509v3 code runs to around 15,000 lines (probably due to the general wackiness of X.509 [1]), and this is a significant amount of additional code to be running in a daemon that accepts input from the network (via a transport that, as Brad points out, can be trivially spoofed).

Lack of Features
(also known as "simplicity"). Guilty as charged.

If you need a feature the OpenNTPD doesn't have (and, indeed there are many), or need greater accuracy than it can provide, or if you just prefer it, then by all means use ntp.org's software (or any other software for that matter). If you want a small daemon that will do a decent job of keeping your clock in sync while running mostly unprivileged, then OpenNTPD may suit. If it does, great. If not, and you decide to use something else, that's fine too. You have another option, which is why I started the Portable branch in the first place.

[1] For an overview of said wackiness, see Peter Gutmann's PKI Tutorial, subtitled "Everything you Never Wanted to Know about PKI but were Forced to Find Out", and for a comprehensive treatment see his X.509 Style Guide).