alt Hacker News> […] (just the time is slightly off/late, but that doesn't help much without a reference to check against.)
The 'time sync' does not need to be done in the same absolutely sense (time_t is the same everywhere), but only in the relative sense:
Various approaches exist for time synchronization [15,16,17,18].
TESLA only requires the receiver to know an upper bound on the delay
of its local clock with respect to the sender's clock, so a simple
algorithm is sufficient.
Knowing the (rough) broadcast delay from sender to receiver is sufficient.
> Knowing the (rough) broadcast delay from sender to receiver is sufficient.
You're citing things without understanding them.
First, you've mangled that summarisation, knowing an upper bound on delay is not the same as knowing delay.
Second, that's true for using TESLA for data streams. Not for when the timing of the stream itself is the information content. That bound on delay translates into a spatial zone of spoofability. The RFC refers to the content being timely (not stale) and authenticated, but timely is not the same as using the timing itself as data.