| httpstime is interesting, but roughtime seems to have a few additional features: * stateless operation (via UDP) * no reliance on SSL/TLS or PKI * ability to catch incorrect servers (assuming no collusion) I think it's a very interesting take on time services, without being something quite as heavy as PTP/IEEE1588. The stated goals of fixing wildly incorrect clocks over ultraprecise timing [0], preventing clock-source tampering, and keeping largely in-line with the original design concepts of ntp (while solving a number of security shortcomings) seems to be targeted squarely at user devices, and much less so at service providers or operators that require precision timing for log stamping and the like. Additionally, if you need a roughly-correct clock for validating HTTPS certificates, and you have to connect to an HTTPS server to update your time to be roughly correct, how do you trust the server? Sure, you can simply connect to something with a self-signed cert, but then you're putting the trust squarely back in the hands of that single server, without any method of verifiability. Turtles all the way down. [0]: "The Roughtime creators state that 25% of Chrome’s certificate errors are caused by incorrect local clocks (off by days or more). A local clock within a few seconds of reference time is good enough." |
The only thing to add is that a tlsdate-like approach will not work consistently with TLS 1.3 as the standard makes time in the handshake OPTIONAL.