* 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.
This should mean cost to serve is cheaper, but I need to read the protocol in more detail.
Use your imagination. Don't forget to combine this with other attacks - if you compromise something your target talks to, for instance, or with non-technical actions - shorting a stock, maybe.
More generally, the two major assumptions that a lot of complex systems depend on are time and identity. There are a lot of games you can play controlling one of those. (Controlling both is better, of course.)
For most crypto applications like certificate expiry, you don't need a particularly accurate clock - +- a day or two is fine - but with Tor the devs have to balance being able to frequently update the consensus with clock accuracy; IIRC the maximum allowable clock skew in Tor is about six hours.
Of course, note how even in that case, if user-experience wasn't an issue you'd be better off telling the user to just look out the window to set their clock than using Roughtime. :)
Nice theme on the blog.