On 28 Apr (13:24:32), Tim Wilson-Brown - teor wrote: > > > On 22 Apr 2016, at 00:46, Michael Rogers <michael@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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. HSDir in 224 don't care anymore about any timestamp. Actually, no timestamp is present in the descriptor anymore, it's only about the revision-counter. This clock skew is useful on the service that is keeping the intro point opens for an extra amount of time for skewed clients. Thus the cache entry adds a clock skew delta to its lifetime for those clients for which we also assume the service will still hold the intro points for that time also. But all this is not an exact science since a service can upload a new descriptor an hour before it rotates its keys then keep the old intro points open for the 3 hours clock skew but then the descriptor will be in the HSDir cache for 30+ hours so a very confused client with an old shared random value will fail anyway... (Heck, I'm not even sure we keep intro point open to accomodate the clock skew on the service side right now.) The best argument I heard for having a clock skew delta is because of mobile where clients often can have a big skewed clock (number unknown...) David > 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 > > > > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev