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.
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?
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)?
(In this example, I assume that 00:00 is the start of the overlap period so the previous SRV is discarded in favor of the "old current" and "current".)
The main issue for me right now is that I can't recall how this helps with clock skewed clients, even though that was a big part of our discussion in Montreal.
Specifically, I think that clients (and HSes) should determine the set of responsible HSDirs (i.e. the current time period) based on the "valid-after" of their latest consensus, instead of using their local clock. This way, as long as the client's skewed clock is good enough to verify the latest consensus, the client will have a consistent view of the network and SRV (assuming an honest/updated dirguard). I tried to clarify this a bit in commit 465156d, so please let me know if it's not a good idea.
Yes I agree. The service gets into "overlap mode" as soon as it can which is getting a consensus with valid-after at 00:00+. The as soon as possible is important because it's a best effort to be available using its knowledge (here the consensus, not local clock).
As for the client, in the mobile world for instance, clock are often quite off where the concensus valid-after has to be "accurate". Chances are that clients and services will have a "similar" consensus (or not that far off from each other, like 03:00 for client and 04:00 for service) thus using that time makes more sense than the local clock. Chances are that client and service have a higher chance to be much further away using the local clock. (I do not have strong evidence of this but it's my intuition.)
So, I agree here that client should use valid-after instead of their local clock. And if they can't validate the consensus time, well #yolo anyway.
Cheers! David
Am I missing something wrt clock skewed clients here? If yes, can someone demonstrate the effects of these changes with an example, so that I can clarify the proposal further?
Feedback is welcome! If I receive positive feedback, I will merge this in torspec.git ASAP.
Thanks!
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev