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

Original Article ↗ Hacker News Discussion ↗

Let’s Encrypt’s deployment of ntpd-rs, a Rust-based Network Time Protocol daemon, is prompting debate over how best to harden critical but low-profile infrastructure like time synchronization. Commenters weigh the benefits of memory safety and protocol security features such as Network Time Security (NTS) against questions of performance compared to chrony, dependency bloat (e.g., JSON libraries), and whether NTP is the highest-priority component to rewrite. Many see NTP as an especially sensitive target because it runs widely on the network edge, underpins certificate validity checks, and has a history of exploitable vulnerabilities in C implementations.

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.