[tor-dev] Revisiting prop224 overlap descriptor logic and descriptor lifetimes

[George Kadianakis]

David Goulet <dgoulet at ev0ke.net> writes:

> [ text/plain ]
> On 13 Jun (15:48:39), George Kadianakis wrote:
>> Hello people,
>> 
>> I invite you to check out another round of time period-related prop224 spec
>> changes, based on our discussions in Montreal. These new changes simplify the
>> overlap descriptor publishing logic, and improve the caching lifetime of
>> descriptors in HSDirs.
>> 
>> You can find them in my branch `prop224-montreal-timeperiods` or here:
>>     https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224-montreal-timeperiods
>
> Couple of things.
>
> Section 2.2.2., about this TODO:
>
>     [TODO: Control republish period using a consensus parameter?]
>
> Right now, we have RendPostPeriod for such a thing and some random added to
> it. As we discussed, a service changing that value will make it different from
> all others and thus more noticeable. But, we cleared out some uses cases where
> it could be useful such as a service load balancing and republishing a new
> descriptor often to change its intro points or keys.
>

I think HSes rotating intro points or keys should publish a new descriptor
regardless of the value of RendPostPeriod. This is not mentioned in prop224 tbh
(maybe it should), but this is also what little-t-tor does currently (it marks
the descriptor as dirty when rotating intro points).

> Making this a consensus params is a good idea imo but we should also provide
> an option to override it. Maybe it could make sense to _only_ have the option
> to change it if you are a NonAnonymous service for instance?
>
> Section 2.2.2.1:
>
>     [TODO: What to do when we run multiple hidden services in a single host?]
>
> This could be quite "obvious" at the Guard. Building at least 12 short live
> circuits is a give away here that I'm running HSes. Apart from adding some
> random offset for each HS (which even then...), I'm not sure how to address
> this. Even now, we just upload all decriptors at the same RendPostPeriod.
> Maybe it's not too big of a problem?
>

Indeed, I'm also unsure on how to handle this properly.

> Section 2.2.5:
>
>     "Hidden services MUST also keep their introduction circuits alive..."
>
> Does that mean service keeps them open (and the keys) until the descriptor
> expires on the HSDir? That is a service uploads a desc at 23:00 but then at
> 00:00 it creates a new descriptor using the new SRV so it should keep the
> intro points open until 02:00 (23:00 + 3 hours lifetime)?
>

Yes, that's what I mean. I will try to add an example to the proposal to make
it more clear.