[tor-dev] Revisiting prop224 time periods and HS descriptor upload/downloads

Thu Apr 28 03:24:32 UTC 2016

> On 22 Apr 2016, at 00:46, Michael Rogers <michael at 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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160428/b081761b/attachment.sig>