Hacker News Reader

Comment by stevekemp | Hacker News Reader

I continue to be surprised by the sheer amount of writing we see about ntpsec. The project was started over two years ago, and yet progress reports seem very optimistic and self-congratulatory, despite an obvious lack of progress.

Sure rewriting "bits" of things, with more features, and adding my python sounds useful. But here we are 500+ days since the project started and there are only minor experiments in moving from C.

I get the feeling this is one of those projects which will never be complete. Perhaps not a bad thing, providing those involved are having fun, but so much verbiage to say so.

View on HN

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".

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).

> 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.

> 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.

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).

Moreover, at the point where you're rewriting ntpd in a new language, you're no longer really producing a hardened version of the original. There already are competing ntpd implementations, if that's all you're after, so this latest excursion into Rust and Go raises the question of whether the project still even makes sense.

To be fair, this was written by ESR. His code to self-congratulatory ratio was pretty high to begin with.

I assume you mean low? :)

This is basically Eric S Raymond's modus operandi. Instead of bikeshedding over Go vs Rust he could have had an MVP up by now

He does, there are releases for NTPsec in C. He's just recently debating about Go vs Rust as a possible transition.

I've been pondering this question too. NTP is a very important Internet service and it's great that folks are looking for a more secure alternative to traditional ntpd. I'm not sure if NTPsec is going to get there or not.

The best alternative out there right now seems to be Chrony. But it hasn't had nearly the inspection and usage ntpd has had, so it's hard to know for sure about its security. ntimed was also looking promising but seems stalled. openntpd doesn't keep time very well and systemd-timesyncd isn't really an NTP implementation.

ESR is a master of just this. He's involved, just ask him :)

http://esr.ibiblio.org/?p=6820

I had the same thought. I will say that that lack of progress may be the exact reason why so much consideration is being put into porting to another language, so as to make faster progress.

Reply on news.ycombinator.com