Hacker News Reader

Comment by jerf | Hacker News Reader

What progress are you looking for? There seem to be downloads here, posted pretty regularly: ftp://ftp.ntpsec.org/pub/releases/

I don't know if they build and work, but I'd suspect they do, based on the refactorings being discussed. The commits seem to be clicking along. A diffstat of roughly where I think they branched off of ntp vs. master takes a moment to poke through, because the raw stats are "1032 files changed, 126489 insertions(+), 143789 deletions(-)", but there's a lot of trading C code for test code and more docs in there.

I don't know exactly what metric you're using but this doesn't match my "obvious lack of progress".

View on HN

They started with Mills ntpd, so there have been downloads available since t0. There's a significant amount of code you can lose from a large C project just by getting rid of ifdefs that nobody uses, so the +/- line count isn't a great metric either.

The true metric for success for something like ntpsec is the number of meaningful security problems ntpd has been vulnerable to since ntpsec's inception that ntpsec hasn't been.

At the point where they rewrite in a new language, they're embarking on a fundamentally different project with a different value proposition, which sort of moots the progress they've made (or not made) on hardening ntpd.

(Fair warning: I am both an ESR skeptic and an ntpsec skeptic; I genuinely do not like the idea behind the ntpsec project).

> The true metric for success for something like ntpsec is the number of meaningful security problems ntpd has been vulnerable to since ntpsec's inception that ntpsec hasn't been.

They talk about 3 areas where bugs have been removed, including:

  Much of ntpd’s most convoluted code lives in ntp_proto.c, which
  implements the state machine central to the protocol. Of the 29
  vulnerabilities that have received CVEs so far in 2016, a couple
  of multi-KLOC functions in ntp_proto.c are responsible for 15 of
  them — just over half. Of course, "just rip it out" wouldn’t
  suffice in this case: this is core business logic, not junk code.
  So we rewrote those functions from scratch, cutting line count
  considerably and yielding a far more readable result.

https://blog.ntpsec.org/2016/12/13/fantastic-bugs-and-where-...

The other two areas are guaranteed bug-free because they removed the code.

From this paragraph you might get the impression that ntpsec had dodged 29 CVEs in 2016. But that's not the impression I have: I think it has been vulnerable to many of the bugs reported in ntpd.

Further: not all CVEs are equivalent, so in addition to wanting to know how many vulnerabilities ntpsec was also vulnerable to, you also want to know what the distribution both of severity and of exposure in the default configuration those bugs had.

Ultimately: I feel about ntpsec the way I would have felt if, in 1997, someone had proposed SendmailSec. The answer to the Sendmail security problem wasn't a "hardened" Sendmail (though the Sendmail team sure tried); it was Postfix and qmail.

> There's a significant amount of code you can lose from a large C project just by getting rid of ifdefs that nobody uses, so the +/- line count isn't a great metric either.

Can't 'ifdefs that nobody uses' hide security flaws? Removing them helps the overall security of the codebase, preventing folks from accidentally enabling a long-dormant codepath, no?

> The true metric for success for something like ntpsec is the number of meaningful security problems ntpd has been vulnerable to since ntpsec's inception that ntpsec hasn't been.

True enough. Are there any numbers on that?

I'm not saying that eliminating unused compile time options is a bad thing, just pointing out that the real security improvements from hardening something like ntpd come from simplifying and eliminating code that is in the default compile that everyone uses.

Really all I'm saying is that you can't get a reliable metric of progress on something like this from a simple line count.

> I genuinely do not like the idea behind the ntpsec project

I don't know the NTP protocol well enough right now, or the aims for the ntpsec project itself. I will say that having a signed response from an NTP server, would raise the trust level of the accuracy of that response. That is, no one can respond with a bogus time and screw up all sorts of stuff.

In terms of privacy/tls etc, that seems less important. But signed messages would be good.

ntpsec isn't a project to revamp or cryptographically improve the NTP protocol; it's an attempt to do for ntpd what BoringSSL and LibreSSL are doing for OpenSSL.

Sort of. The NTS people appear to be ntpsec people: https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp... , and talk about how clearing out the crud (including unused modes) provides enough headroom for the work of adding security.

What you really mean to say there is that Franke is heavily involved both in ntpsec and in modernizing NTP protocol security. :) But the two projects are unrelated. I'm also interested in (and more optimistic about) things like AGL's roughtime:

https://roughtime.googlesource.com/roughtime

... but I acknowledge being somewhat mystified by how much complexity is in NTP given the very minimal needs virtually everyone I've ever worked with had for time synchronization. We all need it, but we don't need it to be ntpd-grade featureful. So this is probably a blind spot for me, and maybe roughtime is less promising than NTS.

Downloads have always been available, as this project was started by taking an existing one - then trying to cut down on things that were insecure, bad, outdated, or similar.

In short this project is very like the forked openssl project. Progress has been made, I can see it, but I think taking two years to turn some existing code into something cleaner is .. surprising.

Especially now that the focus seems to be throwing it away, and starting anew in rust / go (though based on recent updates go seems to be the choice).

Reply on news.ycombinator.com