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

[George Kadianakis]

David Goulet <dgoulet at ev0ke.net> writes:

> [ text/plain ]
> On 11 Apr (14:42:02), George Kadianakis wrote:
>> David Goulet <dgoulet at ev0ke.net> writes:
>> 
>> > [ text/plain ]
>> > On 04 Apr (19:13:39), George Kadianakis wrote:
>> >> Hello,
>> >> 
>> >> during March we discussed the cell formats of prop224:
>> >>   https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html
>> >> 
>> >> The prop224 topic for this month has to do with the way descriptors get
>> >> uploaded and downloaded, how this is scheduled using time periods and how the
>> >> shared randomness subsystem interacts with all that.
>> >> 
>> >> Here are some discussion topics. Lots of text on the first two, less text on the rest:
>> >> 
>> >> <snip>
>> >> 
>> >>   In any case, this is how this might look like:
>> >> 
>> >> 
>> >> 	  +------------------------------------------------------------------+
>> >> 	  |                                                                  |
>> >> 	  | 00:00      12:00       00:00       12:00       00:00       12:00 |
>> >> 	  | SRV#1      TP#1        SRV#2       TP#2        SRV#3       TP#3  |
>> >> 	  |                                                                  |
>> >> 	  |   $         |-----------$-----======|-----------$-----======|    |
>> >> 	  |                            overlap12               overlap23     |
>> >> 	  |                                                                  |
>> >> 	  +------------------------------------------------------------------+
>> >> 
>> >>                                       Legend:    [TP#1 = Time Period #1]
>> >>                                                  [SRV#1 = Shared Random Value #1]
>> >> 
>> >> <snip>
>> >> 
>> 
>> How else could we simplify this logic?
>
> It seems simple enough. Maybe the algorithm I sketched out above makes it
> simpler? Maybe not!... It's basically the _same_ end results as you.
>

Yes, both approaches seem equivalent.

> The logic I sketched out above makes it that we would need parameters (from
> the consensus) like so (or hardcode them):
>
> - TIME_PERIOD_ROTATION_TIME (currently 12:00)
>
> - TIME_PERIOD_[LIFETIME | SPAN | DURATION] (currently 24h)
>
> - SHARED_RANDOM_VALUE_[CREATION | ROTATION]_TIME (currently 00:00)
>
> - SHARED_RANDOM_VALUE_[LIFETIME | SPAN | DURATION] (currently 24h)
>
> I doubt we can go simpler than that. Both algorithms have one single check
> ending in two outcomes that is either use previous or current.
>

So, should we update prop250 and add SHARED_RANDOM_VALUE_CREATION_TIME and
SHARED_RANDOM_VALUE_LIFETIME as consensus parameters?

>> 
>> >> <snip>
>> >> 
>> >>   + HSDir behavior
>> >> 
>> >>     Currently the spec says the following:
>> >> 
>> >> 	   Hidden service directories should accept descriptors at least [TODO:
>> >> 	   how much?] minutes before they would become valid, and retain them
>> >> 	   for at least [TODO: how much?] minutes after the end of the period.
>> >> 
>> >>     After discussion with David, we thought of chopping off the first part of
>> >>     that paragraph and not imposing any such weak restrictions for accepting
>> >>     descriptors (see #18332).
>> >> 
>> >>     We still have not decided about the second part of that paragraph, that is
>> >>     how long descriptors should be retained after the end of the period. We
>> >>     currently think clock skew is the only thing that can bring clients to the
>> >>     wrong HSDir after the end of the period. Maybe an hour is OK? David
>> >>     suggested 12 hours. The current Tor is doing 48 hours... Any ideas?
>> >
>> > It should at least be 24 hours (maximum possible) with an adjustment of at the
>> > _very_ least the overlap period. If the overlap period is 6 hours, we can then
>> > add the "maximum clock skew" we think is reasonable and we would end up with
>> > an OK value imo.
>> >
>> > Descriptor maximum lifetime:    24 hours
>> > Overlap period span:            6 hours (taken from your diagram)
>> > Maximum acceptable clock skew:  6 hours (dgoulet opinion!)
>> >
>> > Thus we are talking of a 36 hours lifetime in the cache. Let's work with that
>> > as a baseline :).
>> >
>> 
>> Hm, I see you are calculating the total lifetime here. How often do hidden
>> services refresh (reupload) their descriptor in this case? I think in the
>> current system, hidden services do so every hour. Do we keep this feature?
>
> I think we can re-upload only when needed that is key rotation, IP rotation,
> etc... No need to do that every hour (maybe).
>

Sounds good to me.

I wonder if there are any negatives to this behavior.

>> 
>> Let's consider a hidden service that uploads a single descriptor during its
>> overlap period and then disappears completely: should the HSDir keep and serve
>> that descriptor for 36 hours? It's unlikely that the HS is still up and
>> maintaining its intro circuits if it can't keep on refreshing its descriptor.
>
> The issue here is for the HSDir to notice that the HS might be gone? And we
> can't rely on RendPostPeriod value since it's service side. So an operator
> could litterally have set that to 7 hours meaning we might not see any new
> revision counter for that period and still unable to tell if the HS is gone or
> not.
>
> This is why our best bet is to compute a "maximum crazy time" that descriptor
> could be valid.
>
> An other option is to add a valid-until field in the cleartext part of the
> descriptor and the HSDir could use that to expire entries plus a clock skew
> delta.
>

Yes, I also thought of adding a valid-until to the cleartext part of the
descriptor so that its lifetime can be tweaked by the hidden service itself.
Of course, HSDirs would also have a maximum desc lifetime that they would enforce.

I wonder if we should do this or maybe it's overengineering and a global
non-configurable default lifetime is OK.

>> 
>> Also consider that whatever "maximum acceptable clock skew" we choose, the
>> hidden service needs to keep its introduction circuits up for that time as
>> well, otherwise the descriptor will be useless to the clock skewed clients.
>
> Yup! This is why I think above 6 hours of clock skewed you won't do much as a
> client... maybe even less!
>
>> 
>> ---
>> 
>> 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. I see the following two negatives here:
>> 
>> - Hidden services need to retain their old intro circuits for the duration of
>>   the acceptable clock skew.
>
> I pretty sure we don't do that currently. However, we could start doing that
> and collect stats on how frequent it is and with how much skew! That would be
> a very useful information to have imo.
>

Yes sounds useful, although we should assume that skewed clients exist in general.

Collecting these statistics on the intro point side requires us to write a
proper statistics patch and do the corresponding security analysis. Collecting
these statistics on the hidden service side, requires us to write a non-trivial
patch that implements this feature and also find volunteers with busy hidden
services to run it. I wonder if it's worth it.