5 ms·

Roughtime – A project that aims to provide secure time synchronisation

73 points by Daviey 10y ago

stephencharles 10y ago
What about the constraints idea from OpenNTPD? i.e., Use timestamps from trusted HTTPS servers. (http://www.undeadly.org/cgi?action=article&sid=20150210103656 http://www.undeadly.org/cgi?action=article&sid=2015021010365...)
- vardump 10y ago
  The problem is what to do when your adversary selectively delays timestamp related packets skewing your time.
  - m45t3r 10y ago
    Note that this isn't exactly a problem in Google case. They want to fix cases where a wrong clock can invalidate certificates, so even a skew of a few minutes wouldn't be a problem (in Roughtime specially, they allow a 10 second delay as far I understand).
- spikengineer 10y ago
  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 10y ago
    openntpd uses the HTTP Date: header, not the faux timestamp in the TLS handshake.
- hannob 10y ago
  openntpd is a nice hacky workaround, but not a clean solution. However they hindered adoption by requiring libressl to build this feature. But roughtime does much more than openntpd: It lets you get the time from multiple servers and gives you cryptographic proof in case one of them tries to lie to you. That's a much tougher security guarantee.
divbit 10y ago
"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 10y ago
  "A man with a watch knows what time it is. A man with two watches is never sure." -- Segal's law
  - viraptor 10y ago
    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.
- wongarsu 10y ago
  >This sounds fairly similar to the 51% attack prevention in Bitcoin With the advantage that in this case you can set an arbitrary threshold. You could for example only update your clock if 80% of your time servers agree on a time, or 90%, depending on your risk aversity. >could one get a reliable ~10 second accurate timestamp from the bitcoin blockchain or a modification of it? You are right that Bitcoin is essentially a timestamping system, but it only timestamps every ten minutes (some other cryptocoins go down to one minute). The protocol is also quite forgiving: you can back-date a block by up to rwo hours. There is also no mechanism for figuring out whether you have all the existing blocks, meaning any blockchain based timeserver could still be tricked into reporting an earlier date by preventing him from receiving the newest blocks. In short I think bitcoin (and other blockchain technology) is great for proving that information already existed on a certain day or even in a certain hour, but I don't think you can make a usable time-synchronization system out of them.
Daviey 10y ago
"[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 10y ago
  Isn't that widely known though? Don't trust random peers on the internet. Hardly a take-away.
  - Daviey 10y ago
    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?
viraptor 10y ago
> 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/ECOSYSTEM.md#Maintaining-a-healthy-software-ecosystem https://roughtime.googlesource.com/roughtime/+/HEAD/ECOSYSTE...
- hannob 10y ago
  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
makomk 10y ago
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.
- viraptor 10y ago
  I don't think they need it every time. With proper error codes it can look like this: while below retry limit: time = get_time if time == error "you use old server ids" refresh list from random source retry Once you get an accepted list, you can either just wait for another error, or refresh only every few days.
- agl 10y ago
  This is a good point and we might need to change things because of this; it depends on what client needs turn out to be. But I'm hoping that the software-update mechanism is the foundation of any modern system, and that can use nonces to show freshness. It's fairly common for systems to update immediately on power-on and hopefully that will get the fresh Roughtime server-list that allows the rest of the system to come up. (The alternative is that we try to guarantee that Roughtime servers will never change, and that's very hard.)
- chongli 10y ago
  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.

73 points by Daviey 10y ago

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

vardump 10y ago
The problem is what to do when your adversary selectively delays timestamp related packets skewing your time.
- m45t3r 10y ago
  Note that this isn't exactly a problem in Google case. They want to fix cases where a wrong clock can invalidate certificates, so even a skew of a few minutes wouldn't be a problem (in Roughtime specially, they allow a 10 second delay as far I understand).
spikengineer 10y ago
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 10y ago
  openntpd uses the HTTP Date: header, not the faux timestamp in the TLS handshake.
hannob 10y ago
openntpd is a nice hacky workaround, but not a clean solution. However they hindered adoption by requiring libressl to build this feature. But roughtime does much more than openntpd: It lets you get the time from multiple servers and gives you cryptographic proof in case one of them tries to lie to you. That's a much tougher security guarantee.

divbit 10y ago

"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 10y ago
"A man with a watch knows what time it is. A man with two watches is never sure." -- Segal's law
- viraptor 10y ago
  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.
wongarsu 10y ago
>This sounds fairly similar to the 51% attack prevention in Bitcoin With the advantage that in this case you can set an arbitrary threshold. You could for example only update your clock if 80% of your time servers agree on a time, or 90%, depending on your risk aversity. >could one get a reliable ~10 second accurate timestamp from the bitcoin blockchain or a modification of it? You are right that Bitcoin is essentially a timestamping system, but it only timestamps every ten minutes (some other cryptocoins go down to one minute). The protocol is also quite forgiving: you can back-date a block by up to rwo hours. There is also no mechanism for figuring out whether you have all the existing blocks, meaning any blockchain based timeserver could still be tricked into reporting an earlier date by preventing him from receiving the newest blocks. In short I think bitcoin (and other blockchain technology) is great for proving that information already existed on a certain day or even in a certain hour, but I don't think you can make a usable time-synchronization system out of them.

Daviey 10y ago

"[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 10y ago
Isn't that widely known though? Don't trust random peers on the internet. Hardly a take-away.
- Daviey 10y ago
  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?

viraptor 10y ago

> 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/ECOSYSTEM.md#Maintaining-a-healthy-software-ecosystem https://roughtime.googlesource.com/roughtime/+/HEAD/ECOSYSTE...

hannob 10y ago
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

makomk 10y ago

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.

viraptor 10y ago
I don't think they need it every time. With proper error codes it can look like this: while below retry limit: time = get_time if time == error "you use old server ids" refresh list from random source retry Once you get an accepted list, you can either just wait for another error, or refresh only every few days.
agl 10y ago
This is a good point and we might need to change things because of this; it depends on what client needs turn out to be. But I'm hoping that the software-update mechanism is the foundation of any modern system, and that can use nonces to show freshness. It's fairly common for systems to update immediately on power-on and hopefully that will get the fresh Roughtime server-list that allows the rest of the system to come up. (The alternative is that we try to guarantee that Roughtime servers will never change, and that's very hard.)
chongli 10y ago
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.