
Roughtime – A project that aims to provide secure time synchronisation - Daviey
https://roughtime.googlesource.com/roughtime/
======
makomk
From the Ecosystem page: "So, instead, Roughtime is only available for
products that can be updated. The server lists have an explicit expiry time in
them and we will actively seek to break clients that try to use old
information in order to maintain ecosystem health. At the moment changing the
hostname or port of a server is the easiest way to enforce this but we expect
to add a per-server id in the future that clients would need to send in order
to prove to the server that they have a current server list."

I see a slight chicken and egg problem here. This service is mostly needed to
provide initial time synchronization to devices that have just powered on and
don't know what time it is - but of course, since they don't know the time
_they have no way of checking the freshness of the server list_. Which in
practice means that a lot of devices will end up having to download a new
server list every time they need to synchronize their time. That's a lot of
load on the server providing the list, which effectively becomes a critical
part of the Roughtime system that's hardcoded into the clients.

~~~
chongli
Why not just use a hash of the server list to query whether or not you're up
to date? You ping the server with your hash and it replies OK or it sends you
the latest one.

~~~
wongarsu
That reduces the impact of each query, but doesn't reduce the amount of
queries.

Imagine if a few popular models of IoT devices take security seriously and get
their time with roughtime. They are still built from cheap components with
minimal capability for persistent writes though, because price is key. Any
large blackout could mean that millions of these devices power up
simultaniously, putting huge load on the list update server.

You essentially make the list update servers crucial infrastructure that has
to potentially handle huge load spikes.

------
viraptor
> Since we require that requests be padded to 1KB to avoid becoming a DDoS
> amplifier

This is an interesting solution I've never seen in practice before.

Also fault injection is pretty novel. I haven't seen this anywhere before.
Essentially a public "opportunistic fuzzing" system:
[https://roughtime.googlesource.com/roughtime/+/HEAD/ECOSYSTE...](https://roughtime.googlesource.com/roughtime/+/HEAD/ECOSYSTEM.md#Maintaining-
a-healthy-software-ecosystem)

~~~
hannob
The fault injection is similar to the "GREASE" concept that AGL's colleague
David Benjamin designed for TLS: [https://tools.ietf.org/html/draft-davidben-
tls-grease-01](https://tools.ietf.org/html/draft-davidben-tls-grease-01)

------
stephencharles
What about the constraints idea from OpenNTPD? i.e., Use timestamps from
trusted HTTPS servers.
([http://www.undeadly.org/cgi?action=article&sid=2015021010365...](http://www.undeadly.org/cgi?action=article&sid=20150210103656))

~~~
spikengineer
HTTPS servers will no longer offer timestamps from TLS 1.3 onwards since that
feature is being deprecated due to performance reasons.

Any such clients have to fall back to TLS 1.2

A TLS 1.0 to 1.2 based time sync client called 'tlsdate' already exists.

~~~
tedunangst
openntpd uses the HTTP Date: header, not the faux timestamp in the TLS
handshake.

------
divbit
"With only two servers, the client can end up with proof that something is
wrong, but no idea what the correct time is. But with half a dozen or more
independent servers, the client will end up with a chain of proof of any
server's misbehaviour, signed by several others, and (presumably) enough
accurate replies to establish what the correct time is."

This sounds fairly similar to the 51% attack prevention in Bitcoin, and I
think they could perhaps be more precise here. There are several other
similarities which stuck out to me (note that bitcoin itself is a timestamp
server, see section 3 of the whitepaper).

Also they mention "We envision that clients will maintain a rolling window of
signature chains and will be able to upload any proofs of misbehaviour," which
also sounds bitcoin-ish at least to me.. (maybe my perception is skewed from
spending lots of time in the space)

I guess the question this leaves me with after reading is: could one get a
reliable ~10 second accurate timestamp from the bitcoin blockchain or a
modification of it?

~~~
Daviey
"A man with a watch knows what time it is. A man with two watches is never
sure." \-- Segal's law

~~~
viraptor
This doesn't seem to apply to time synchronisation really. Here, the more
watches you have, the better your idea of what the time is.

------
Daviey
"[Secure NTP] But that's what NTP should have been, 15 years ago—it just
allows the network to be untrusted. We aim higher these days"..... So the
infra/servers cannot be trusted.. THIS is the real takeaway.

~~~
bluecmd
Isn't that widely known though? Don't trust random peers on the internet.
Hardly a take-away.

~~~
Daviey
Not talking about random peers...

Do you currently trust your LAN?

Do you not currently have some level of trust with pool.ntp.org or your OS
hosted ntp mirrors?

