David Goulet <[email protected]> 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. _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
