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

[David Goulet]

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.

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160614/741a9f34/attachment.sig>