Meta adds Network Time Security to its public time service, nts.meta.com

Plain NTP trusts whatever answers. Meta describes it this way: the client sends 48 bytes, something sends 48 bytes back, and the client believes it, with no signature and no identity ^[5]. That is a generous trust model for the input every expiry check reads. Certificate notBefore and notAfter fields, token lifetimes and replay windows are all compared against the local clock, and logs from two hosts only line up if their clocks agree ^[6].

Certificates also make the problem circular. X.509 date validation needs the current time before the device has a trusted one ^[7]. Meta lists two workarounds ^[8]. Devices can skip validation until the clock is set. Or issuers can backdate notBefore by a few minutes while validators widen the window at their end ^[8]. "Both sides are guessing at how wrong the other one is," Meta's engineers wrote ^[9]. Meta calls that guessing survivable when a certificate lasted 398 days ^[10]. The 2029 cap is about 8.5 times shorter ^[16].

NTS splits the work into two phases. The first is NTS-KE, a TLS 1.3 session on TCP port 4460 negotiated with ALPN ntske/1 ^[12]. Client and server pick an AEAD and derive two directional session keys from the TLS session through the RFC 5705 exporter ^[12]. The server then hands over eight cookies and a record naming the NTP server to use, and closes the connection ^[12]. This happens once, not per packet ^[12]. Meta negotiates three AEADs and lets the client's preference win ^[13]. AES-SIV-CMAC-256 is the one RFC 8915 makes mandatory to implement, so it is what an unknown client is most likely to ask for ^[13].

Phase two is ordinary NTPv4 on UDP 123 with NTS extension fields ^[14]. Each request carries a unique identifier, a cookie and an authenticator that protects the fields ahead of it in the packet while leaving them in plaintext ^[14]. The server decrypts the cookie to get the session keys back, then verifies the authenticator. It replies with the identifier echoed back and an authenticator of its own, whose encrypted payload is a set of fresh cookies ^[15].

The cookie is how the server stays stateless. It brings the client's session keys back on every request, and the server opens it to recover them ^[15]. Meta says its servers hold no per-client state, and that cookie keys are derived, not stored and not replicated ^[2]. I think this is the right tradeoff for a public endpoint serving clients it has never seen. The server spends one cookie decryption per request and keeps no session table ^[15].

Where it breaks is first boot. NTS-KE is a TLS 1.3 handshake ^[12], and Meta's post itself says X.509 date checks cannot run without the current time ^[7]. So a device whose clock is far off has to validate the key-exchange server's certificate before it has any authenticated time. Meta's description of the two phases does not address that case.