
Scalable, Lie-Detecting Timeserving with Roughtime - int08h
https://int08h.com/post/to-catch-a-lying-timeserver/
======
jcvhaarst
Aren't all the goals already met by e.g.
[http://phk.freebsd.dk/time/20151212.html](http://phk.freebsd.dk/time/20151212.html)
?

~~~
packetized
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."

~~~
int08h
I was typing up a response, but yours is great. You nailed it.

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.

~~~
packetized
It's been a couple of years since I was really immersed in the operational
aspects of NTP/PTP - glad to know I can still mostly follow along.

Nice theme on the blog.

~~~
int08h
Thank you.

------
dennyabraham
What would the magnitude of effort to actually replace ntp with another
solution be? Even in low-level programming, I mostly take for granted that it
occurs, but it's regular enough that there's an ntpd on any machine I connect
to.

------
macsj200
What does someone stand to gain by lying about the time?

~~~
mcpherrinm
Say you've gotten your hands on an old, expired TLS certificate (or cracked
one using old crypto). Then, if you can convince a client it's in the past,
you can use that to mount an attack.

~~~
petertodd
Tor has a related problem where the Tor consensus is only valid for a specific
time window - if you use the consensus outside that time window you may end up
using a completely different set of nodes than what everyone else is using,
potentially greatly reducing your anonymity.

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. :)

