From owner-freebsd-security@freebsd.org  Sat Apr 30 13:45:09 2016
Return-Path: <owner-freebsd-security@freebsd.org>
Delivered-To: freebsd-security@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91241B1F8C5
 for <freebsd-security@mailman.ysv.freebsd.org>;
 Sat, 30 Apr 2016 13:45:09 +0000 (UTC)
 (envelope-from news@mips.inka.de)
Received: from mail.inka.de (quechua.inka.de
 [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c])
 (using TLSv1 with cipher AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 4C3641942
 for <freebsd-security@freebsd.org>; Sat, 30 Apr 2016 13:45:09 +0000 (UTC)
 (envelope-from news@mips.inka.de)
Received: from mips.inka.de (news@[127.0.0.1])
 by mail.inka.de with uucp (rmailwrap 0.5) 
 id 1awVCk-0002w9-0F; Sat, 30 Apr 2016 15:45:06 +0200
Received: from lorvorc.mips.inka.de (localhost [127.0.0.1])
 by lorvorc.mips.inka.de (8.15.2/8.15.2) with ESMTP id u3UDhYbm074089
 for <freebsd-security@freebsd.org>; Sat, 30 Apr 2016 15:43:34 +0200 (CEST)
 (envelope-from news@lorvorc.mips.inka.de)
Received: (from news@localhost)
 by lorvorc.mips.inka.de (8.15.2/8.15.2/Submit) id u3UDhYPj074088
 for freebsd-security@freebsd.org; Sat, 30 Apr 2016 15:43:34 +0200 (CEST)
 (envelope-from news)
To: freebsd-security@freebsd.org
From: Christian Weisgerber <naddy@mips.inka.de>
Newsgroups: list.freebsd.security
Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp
Date: Sat, 30 Apr 2016 13:43:34 +0000 (UTC)
Message-ID: <slrnni9dk6.27hm.naddy@lorvorc.mips.inka.de>
References: <20160429082953.DB31D1769@freefall.freebsd.org>
 <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu>
 <1461929003.67736.2.camel@yandex.com>
 <CINIP100NTSBSRqf69a0000002a@cinip100ntsbs.irtnog.net>
 <BABF8C57A778F04791343E5601659908237051@cinip100ntsbs.irtnog.net>
User-Agent: slrn/1.0.2 (FreeBSD)
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Security issues \[members-only posting\]"
 <freebsd-security.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security/>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Apr 2016 13:45:09 -0000

On 2016-04-29, "Matthew X. Economou" <xenophon@irtnog.org> 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.

OpenNTPD is intended to cover the most common usage scenarios.

The single most common use of NTP is a client that simply gets the
time from a server or set of servers.  The second most common use
is a server that fetches the time from other servers and redistributes
it to a bunch of clients.   These two scenarios cover what, 99% of
all ntpd users?

(OpenNTPD also has support for reference clocks, but that code uses
OpenBSD's sensor framework and is not portable.)

> As a conscious design choice, OpenNTPD trades off accuracy
> for code simplicity.

There has been no such design choice.  OpenNTPD is simply accurate
enough in practice that the matter hasn't really come up.

Accuracy is a complete red herring if you are getting your time
from the Internet, where packet jitter is a few milliseconds anyway.

> It lacks support for NTP authentication, access controls,
> reference clocks, multicast/broadcast operation, or any kind of
> monitoring/reporting.

Only a tiny fraction of NTP users will use any of that.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de