David Goulet <[email protected]> writes: > [ text/plain ] > On 11 Apr (14:42:02), George Kadianakis wrote: >> David Goulet <[email protected]> writes: >> >> > [ text/plain ] >> > On 04 Apr (19:13:39), George Kadianakis wrote: >> >> Hello, >> >> >> >> during March we discussed the cell formats of prop224: >> >> https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html >> >> >> >> The prop224 topic for this month has to do with the way descriptors get >> >> uploaded and downloaded, how this is scheduled using time periods and how >> >> the >> >> shared randomness subsystem interacts with all that. >> >> >> >> Here are some discussion topics. Lots of text on the first two, less text >> >> on the rest: >> >> >> >> <snip> >> >> >> >> In any case, this is how this might look like: >> >> >> >> >> >> +------------------------------------------------------------------+ >> >> | | >> >> | 00:00 12:00 00:00 12:00 00:00 12:00 | >> >> | SRV#1 TP#1 SRV#2 TP#2 SRV#3 TP#3 | >> >> | | >> >> | $ |-----------$-----======|-----------$-----======| | >> >> | overlap12 overlap23 | >> >> | | >> >> +------------------------------------------------------------------+ >> >> >> >> Legend: [TP#1 = Time Period #1] >> >> [SRV#1 = Shared Random >> >> Value #1] >> >> >> >> <snip> >> >> >> >> How else could we simplify this logic? > > It seems simple enough. Maybe the algorithm I sketched out above makes it > simpler? Maybe not!... It's basically the _same_ end results as you. >
Yes, both approaches seem equivalent. > The logic I sketched out above makes it that we would need parameters (from > the consensus) like so (or hardcode them): > > - TIME_PERIOD_ROTATION_TIME (currently 12:00) > > - TIME_PERIOD_[LIFETIME | SPAN | DURATION] (currently 24h) > > - SHARED_RANDOM_VALUE_[CREATION | ROTATION]_TIME (currently 00:00) > > - SHARED_RANDOM_VALUE_[LIFETIME | SPAN | DURATION] (currently 24h) > > I doubt we can go simpler than that. Both algorithms have one single check > ending in two outcomes that is either use previous or current. > So, should we update prop250 and add SHARED_RANDOM_VALUE_CREATION_TIME and SHARED_RANDOM_VALUE_LIFETIME as consensus parameters? >> >> >> <snip> >> >> >> >> + 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 :). >> > >> >> Hm, I see you are calculating the total lifetime here. How often do hidden >> services refresh (reupload) their descriptor in this case? I think in the >> current system, hidden services do so every hour. Do we keep this feature? > > I think we can re-upload only when needed that is key rotation, IP rotation, > etc... No need to do that every hour (maybe). > Sounds good to me. I wonder if there are any negatives to this behavior. >> >> Let's consider a hidden service that uploads a single descriptor during its >> overlap period and then disappears completely: should the HSDir keep and >> serve >> that descriptor for 36 hours? It's unlikely that the HS is still up and >> maintaining its intro circuits if it can't keep on refreshing its descriptor. > > The issue here is for the HSDir to notice that the HS might be gone? And we > can't rely on RendPostPeriod value since it's service side. So an operator > could litterally have set that to 7 hours meaning we might not see any new > revision counter for that period and still unable to tell if the HS is gone or > not. > > This is why our best bet is to compute a "maximum crazy time" that descriptor > could be valid. > > An other option is to add a valid-until field in the cleartext part of the > descriptor and the HSDir could use that to expire entries plus a clock skew > delta. > Yes, I also thought of adding a valid-until to the cleartext part of the descriptor so that its lifetime can be tweaked by the hidden service itself. Of course, HSDirs would also have a maximum desc lifetime that they would enforce. I wonder if we should do this or maybe it's overengineering and a global non-configurable default lifetime is OK. >> >> Also consider that whatever "maximum acceptable clock skew" we choose, the >> hidden service needs to keep its introduction circuits up for that time as >> well, otherwise the descriptor will be useless to the clock skewed clients. > > Yup! This is why I think above 6 hours of clock skewed you won't do much as a > client... maybe even less! > >> >> --- >> >> FWIW, I'm personally not sure how to choose the best "maximum acceptable >> clock skew" >> value here. My intuition tells me to choose a big number so that even very >> skewed clients can visit hidden services. I see the following two negatives >> here: >> >> - Hidden services need to retain their old intro circuits for the duration of >> the acceptable clock skew. > > I pretty sure we don't do that currently. However, we could start doing that > and collect stats on how frequent it is and with how much skew! That would be > a very useful information to have imo. > Yes sounds useful, although we should assume that skewed clients exist in general. Collecting these statistics on the intro point side requires us to write a proper statistics patch and do the corresponding security analysis. Collecting these statistics on the hidden service side, requires us to write a non-trivial patch that implements this feature and also find volunteers with busy hidden services to run it. I wonder if it's worth it. _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
