On 22 Apr 2016, at 00:46, Michael Rogers michael@briarproject.org wrote:
On 11/04/16 12:42, George Kadianakis wrote:
FWIW, I'm personally not sure how to choose the best "maximum acceptable clock skew" value here. My intuition tells me to choose a big number so that even very skewed clients can visit hidden services.
Sorry for the late reply. I just wanted to mention that mobile clients often have very skewed clocks because some users adjust the time rather than the timezone when travelling. Disapprove if you like, I share your disapproval, but that's what the kids are doing these days.
Also, if the hidden service and the client are both running on mobile devices, the relative skew can be twice as much.
On 13 Apr (15:34:54), George Kadianakis wrote:
It also adds the following section:
HSDirs MUST retain hidden service descriptors for 33 hours before expiring
them. That's 24 hours for the time period duration, plus 6 hours for the
maximum overlap period span, plus 3 hours for the maximum acceptable client
clock skew.
Hidden services should keep their old introduction circuits open for at
least 3 hours after descriptor expiration, so that clients with skewed
clocks can still visit them through outdated descriptors.
This implements the naive cache lifetime mechanic we discussed in this thread. That's an improvement over the empty TODO section of the current prop224 but maybe we can do better: we should think whether we want to do more advanced HSDir heuristics like "If I'm an HSDir and I don't receive an HS descriptor for N hours, consider that HS dead". Or maybe we should add valid-until fields to hidden service descriptors. Thoughts?
On 21 Apr 2016, at 19:55, George Kadianakis desnacked@riseup.net wrote:
Before doing this we should make sure that nothing will break if we bring the 72 hours v2 lifetime down to 33 hours. Personally, I can't think of anything breaking right now.
The proposal is to set: REND_CACHE_MAX_SKEW to 3 hours (down from 24 hours) REND_CACHE_MAX_AGE to 30 hours (down from 48 hours) (24 hours for the period, and 6 hours for the maximum overlap)
The maximum time zone difference is 26 hours.[0] So I think we should make REND_CACHE_MAX_SKEW 28 hours to accomodate users who change their clock, rather than their timezone. (This allows for an additional timezone change East or West, or a user off-by-one-hour. However, it doesn't allow for the user getting the day wrong in the wrong direction. I think this is ok.)
Regardless of client clock issues, the directory authorities only drop relays from the consensus when their skew reaches 12 hours in the future, or 24 hours in the past. This is an argument for making the REND_CACHE_MAX_SKEW at least 24 hours, to accomodate HSDirs with bad clocks. Otherwise, a HSDir with a clock skewed 3 hours into the past would start rejecting valid descriptors.
It's also worth noting that HSDirs believe the date in the signed descriptor, even if it's badly skewed. This means a forward-dated descriptor is preferred under memory pressure, which is a property I don't like. I suggest we evict cache entries when either: * they have spent a lot of time in the cache since the time they were received, or * their signed date is old.
Other factors:
My understanding is that the consensus can be downloaded before the clock is changed, and successfully used afterwards. (At least if the skew is less than 24 hours in the past or 27 hours in the future.)
But I haven't looked into the details of whether a client could connect to a hidden service with a skew this high. How much skew clients and hidden services can have before TLS or Tor-specific crypto fails? Does anyone want to spin up a VM and work this out?
In the interim, let's assume the crypto will work, and modify the proposal with a larger clock skew.
Tim
[0]: https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n