Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Roughtime: a protocol for secure, auditable time synchronisation

imperialviolet.org

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Roughtime: a protocol for secure, auditable time synchronisation

#11

Post by sargun »

rarrrrrr wrote: post #10

SpiderOak might be interested in running a Roughtime service / participating in a Roughtime community to support Semaphor. As it is, Semaphor clients include a local timestamp among the signed content of most actions, and the server rejects actions that aren't within some tolerance (strict ordering however is accomplished via hash chain.) Roughtime would allow improving this situation from several angles. One of the…

At the bottom of the page, they mention to get in touch, either via the mailing list (https://groups.google.com/a/chromium.org/forum/#!forum/proto...), or directly.

Re: Roughtime: a protocol for secure, auditable time synchronisation

#12

Post by pcl »

amluto wrote: post #9
pcl wrote: post #7

Earlier quoted context omitted.

I'm curious why the clients chain requests but the servers don't chain replies. One challenge would be around server scale -- for the servers to maintain a strict chain, they would need to coordinate amongst themselves, which can be costly. The proposed approach doesn't introduce that requirement. But they could get close by maintaining a branching history, like what you might see in a git history, or a vector clock.…

I just meant for servers to maintain a local chain. Cross-server checking would be free, sort of, as clients that talk to multiple servers would inject the chain state from the first server into the second via their nonces.

At scale, a time server's DNS address will likely either be a reverse proxy or a multi-valued A record. The coordination amongst those separate physical servers that are serving requests for the same DNS name would become a scale challenge if they needed to share state.

Re: Roughtime: a protocol for secure, auditable time synchronisation

#13

Post by OrpheanBeholder »

> There have been efforts to augment NTP with authentication, but they still assume a world where each client trusts one or more time servers absolutely.

OpenNTPD has "constraints" where it makes HTTP requests (using TLS) to webservers and checks that the time provided by the NTP server is within a certain threshold of the time returned in the HTTP Date header.

Much simpler and doesn't require dedicated servers.

Re: Roughtime: a protocol for secure, auditable time synchronisation

#14

Post by dsl »

OrpheanBeholder wrote: post #13

> There have been efforts to augment NTP with authentication, but they still assume a world where each client trusts one or more time servers absolutely. OpenNTPD has "constraints" where it makes HTTP requests (using TLS) to webservers and checks that the time provided by the NTP server is within a certain threshold of the time returned in the HTTP Date header. Much simpler and doesn't require dedicated servers.

tlsdate is a much cleaner implementation of this idea, taking the time from the handshake. TLS 1.3 as it stands makes sending the server time optional.

The 'Date' header is tricky because it is a timestamp of when the document was generated, not when it was served. Caching proxies have no obligation to (and in most cases shouldn't) update the value.

Re: Roughtime: a protocol for secure, auditable time synchronisation

#15

Post by OrpheanBeholder »

dsl wrote: post #14
OrpheanBeholder wrote: post #13

> There have been efforts to augment NTP with authentication, but they still assume a world where each client trusts one or more time servers absolutely. OpenNTPD has "constraints" where it makes HTTP requests (using TLS) to webservers and checks that the time provided by the NTP server is within a certain threshold of the time returned in the HTTP Date header. Much simpler and doesn't require dedicated servers.

tlsdate is a much cleaner implementation of this idea, taking the time from the handshake. TLS 1.3 as it stands makes sending the server time optional. The 'Date' header is tricky because it is a timestamp of when the document was generated, not when it was served. Caching proxies have no obligation to (and in most cases shouldn't) update the value.

Some TLS implementations return a randomised date for the handshake anyway, which is why constraints works the way it does. TLS 1.3 killing it is just gravy.

If you're worried about a caching proxy you can set the constraint to a URL that returns something dynamic. Although it would be interesting to see what % of the top TLS-enabled webservers don't return something recent for HEAD / HTTP/1.1

Re: Roughtime: a protocol for secure, auditable time synchronisation

#17

Post by amluto »

pcl wrote: post #12
amluto wrote: post #9

Earlier quoted context omitted.

I just meant for servers to maintain a local chain. Cross-server checking would be free, sort of, as clients that talk to multiple servers would inject the chain state from the first server into the second via their nonces.

At scale, a time server's DNS address will likely either be a reverse proxy or a multi-valued A record. The coordination amongst those separate physical servers that are serving requests for the same DNS name would become a scale challenge if they needed to share state.

But they wouldn't need to share state. They could run independently, and any client that wanted to tie their clocks together could request the signed time from one and then send it to the other, causing it to get logged in the other server's chain.
Post reply on HN