David Goulet dgoulet@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-t...
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.