On 2014/2/19 12:20 PM, Richard Newman wrote: >> One approach we took was that the Server Timestamp is generally >> distributed with every response from the server (The "Date:" header). >> The client simply recorded the difference between the server and local >> clock skew, and added that difference to the TS value used in the OAuth >> headers. > > That's pretty much the approach Hawk takes: the timestamp range limitation > approximates the circular buffer of nonces, and the clients use the server > timestamp to correct their time for the purpose of authenticating to that > particular server. > > The issue here is that we have three tiers of servers, each of which's clock > might differ, the third tier of which can change (different storage servers), > and a client clock that can be adjusted while we're working. Add in > questionable latency and the temptation to persist skews across restarts, and > things become complex -- and, I might add, complex without eliminating some > non-trivial percentage of errors. > > The OpenSignal folks suggest using the realtime clock in combination with > some kind of anchoring ping to simulate an independent monotonic clock on > Android. That seems like a reasonable idea -- "fake NTP". > > But the fact remains that this seems like a spiderweb of complexity that > doesn't really meet our needs… > Huh, sounds like the problem is that we're dual using a value. Timestamps have two roles: Signatory (make the HMAC work) and Regulatory (No, you are not from the future). For Signatory, a timestamp can be passed through as a somewhat predictable nonce and servers can ignore the actual value. For Regulatory, though, things become more complicated, and I'd argue that those should be dealt with between nodes, and there may need to be an additional value exchanged (via header?) to indicate the clock skew between machines.
I guess this gets to the "fake NTP" idea, but that just seems chock full o' dragons. I'd probably go with a vector clock instead. _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
