[tor-dev] Revisiting prop224 time periods and HS descriptor upload/downloads

Tue Apr 5 11:56:50 UTC 2016

On 05 Apr (12:59:36), Tim Wilson-Brown - teor wrote:
> 
> > On 5 Apr 2016, at 02:54, David Goulet <dgoulet at ev0ke.net> wrote:
> > So, this basically gives a space of 12 hours between the SRV generation and
> >  the start of the next time period. We can then easily fit an overlap period
> >  of 6 hours before the next time periods starts.
> 
> You've implicitly adjusted hsdir-overlap-begins to 75 here.
> I think that's ok, but it does need to be modified in the spec.
> 
> >> + Hidden Service behavior:
> >> 
> >>    Example 1: Our hidden service boots up at 14:00 of TP#1. In this case, we
> >>     are nowhere close to the overlap period, so the hidden service should just
> >>     publish its TP#1 descriptor to the HSDir hash ring using SRV#1 (which at
> >>     that point should be in consensuses as "shared-rand-current-value").
> >> 
> >>     The hidden service might also want to calculate its overlap OFFSET (as
> >>     specified in [TIME-OVERLAP]) and schedule a time callback for publishing
> >>     its TP#2 descriptors.
> >> 
> >>    Example 2: Our hidden service boots up at 03:00 of TP#1. That's outside of
> >>     the overlap period again, but this time the hidden service needs to use the
> >>     SRV from "shared-rand-previous-value" because the SRV was rotated at midnight.
> >> 
> >>    Example 3: Our hidden service boots up at 09:00 of TP#1. That's inside the
> >>     overlap period, so the hidden service should calculate its overlap
> >>     OFFSET and compare it with the current time.
> >> 
> >>     If it has not passed, then we are in the exact same case as Example 2.
> >> 
> >>     If the overlap OFFSET _has_ passed, then the hidden service needs to act
> >>     as Example 2, and _also_ publish its TP#2 descriptors to a second set of
> >>     HSDirs using SRV#2.
> >> 
> >>    I think these are all the cases for the hidden service, but I would like to
> >>    formalize this in a way that can be written in the spec. Particularly, I'm
> >>    not sure how to formalize which SRV to pick at a given time point.
> > 
> > It sounds simple as:
> > 
> > "If we are before to the overlap period, use the time period shared random
> > value (TP1 == SRV1). If we are in the overlap period, upload two descriptors
> > using _both_ SRVs."
> > 
> > Plausible?
> 
> Almost: it needs to say "overlap offset for the next blinded key"
> (the overlap varies based on the specific key).
> 
> >>  + Client behavior
> >> 
> >>    My current intuition with regards to client behavior is that they should
> >>    always fetch descriptors from the HSDirs of the _current_ time period. They
> >>    should not concern themselves with the overlap stuff _at all_. The overlap
> >>    system is there so that by the time the new time period starts, all the
> >>    HSDirs have received the descriptors and are ready to help the
> >>    clients. Clients should never notice the overlap stuff happening.
> > 
> > 100% agreed.
> > 
> > Clock skew though might bring reachability issue where the client tries
> > descriptor #1 but it's been an hour that the #2 is suppose to be used (TP2).
> > But, we can probably solve that by having the HS keep its IPs open for the
> > descriptor #1 for a period of X hours to accomodate those confused clients.
> > 
> > (I bet X could be between 4 to 6 hours at best. Altough, I have no clue how
> > much a client can function with that big of a skew.)
> > 
> > Anyway, the point is that it's not the cliet job to adjust imo.
> 
> Clients can use a consensus and HS descriptors that are 24 hours out of date:
> NETWORKSTATUS_ALLOW_SKEW

This doesn't seem to be used anywhere.

> REND_CACHE_MAX_SKEW

This is imo way to big.
https://trac.torproject.org/projects/tor/ticket/13207

We should take the opportunity of 224 implementation to come up with something
that make sense imo. Could be 24h but I doubt it right now.

> 
> So our skew should be at least that much.
> 
> >>    For this reason I think we can remove this paragraph from the spec:
> >> 
> >> 	   When a client is looking for a service, it must calculate its key
> >> 	   both for the current and for the subsequent period, to decide whether
> >> 	   the next period's key is valid yet.
> >> 
> >>    What do you think?
> > 
> > Rip it off :).
> 
> It seems like an extra complication.
> I can't see how it helps clients to have 12 HSDirs to choose from for some
> random time between 0 and 6 hours each period.
> 
> (If we decide it does later, we can add the feature in a client update.
> We just need to make sure that HSDirs will answer queries for descriptors
> that aren't valid yet, which makes sense to do for client skew anyway.)
> 
> >>  + HSDir behavior
> >> 
> >>    Currently the spec says the following:
> >> 
> >> 	   Hidden service directories should accept descriptors at least [TODO:
> >> 	   how much?] minutes before they would become valid, and retain them
> >> 	   for at least [TODO: how much?] minutes after the end of the period.
> >> 
> >>    After discussion with David, we thought of chopping off the first part of
> >>    that paragraph and not imposing any such weak restrictions for accepting
> >>    descriptors (see #18332).
> >> 
> >>    We still have not decided about the second part of that paragraph, that is
> >>    how long descriptors should be retained after the end of the period. We
> >>    currently think clock skew is the only thing that can bring clients to the
> >>    wrong HSDir after the end of the period. Maybe an hour is OK? David
> >>    suggested 12 hours. The current Tor is doing 48 hours... Any ideas?
> > 
> > It should at least be 24 hours (maximum possible) with an adjustment of at the
> > _very_ least the overlap period. If the overlap period is 6 hours, we can then
> > add the "maximum clock skew" we think is reasonable and we would end up with
> > an OK value imo.
> > 
> > Descriptor maximum lifetime:    24 hours
> > Overlap period span:            6 hours (taken from your diagram)
> > Maximum acceptable clock skew:  6 hours (dgoulet opinion!)
> > 
> > Thus we are talking of a 36 hours lifetime in the cache. Let's work with that
> > as a baseline :).
> 
> Let's make it 24 + 24 + 6 = 54 hours instead, based on the 24 hour skew
> allowed for current clients. (See above.)

I'm still doubtful :).

David

> 
> Tim
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP 968F094B
> 
> teor at blah dot im
> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
> 

> _______________________________________________
> 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/20160405/eb5871a0/attachment.sig>