More Memory Safety for Let's Encrypt: Deploying ntpd-rs

Original Article ↗ Hacker News Discussion ↗

JSON, Observability, and Dependencies

  • ntpd-rs uses JSON to expose internal state and metrics via a Unix socket; a separate Prometheus daemon and client tool consume this.
  • Some question adding a JSON library for limited use, suggesting manual JSON/string construction or alternative formats (TSV, simple custom).
  • Others argue hand-rolled JSON/TSV is fragile (escaping, control chars, truncation) and can cause bugs or downstream vulnerabilities.
  • Debate over config formats: JSON/TOML/YAML vs minimal bespoke formats (e.g., INI-like, OpenBSD-style).
    • Pro-standard formats: fewer custom parsers, predictable syntax, reusable tooling.
    • Pro-bespoke: tiny parsers, fewer dependencies, simpler threat surface, easier long-term stability.

Performance and Timekeeping

  • Several commenters care more about timekeeping quality than language choice, especially compared with chrony.
  • Project contributors report ntpd-rs is close to, and sometimes better than, chrony in internal tests; algorithm docs and data are published.
  • There is interest in GPS/PTS integration; project also includes a PTP implementation (statime).
  • Discussion notes NTP can match or beat PTP precision given hardware timestamping and multiple time sources, but hardware typically favors PTP.

Security, Memory Safety, and Threat Model

  • Some see ntpd as a low-priority target for memory-safety work; others argue it’s exactly the kind of ubiquitous, network-facing, time-critical service that merits hardening.
  • NTP issues raised: runs with elevated privileges, parses bespoke binary packets, usually unauthenticated, and underpins TLS certificate validity.
  • Historical C NTP implementations have had multiple CVEs; proponents argue any network boundary service should avoid C/C++ where possible.
  • There is extended discussion explaining memory unsafety in C/C++ and why OS-level crashes do not guarantee safety against exploitation.

NTS and UDP Amplification

  • Key risk areas: spoofable UDP, reflection/amplification, and synchronized client behavior causing unintended load spikes.
  • Network Time Security (NTS, RFC 8915) is discussed as a major improvement: TLS-based key exchange plus authenticated NTP packets.
  • ntpd-rs and other implementations support NTS, but adoption is described as low; many systems still use unauthenticated NTP.
  • Challenges cited for NTS in public pools (key sharing, centralized NTS-KE) and ideas for certificate-based coordination.
  • ntpd-rs deliberately avoids legacy management commands like monlist and limits response sizes to prevent amplification.