On 12 Apr (20:58:43), Tim Wilson-Brown - teor wrote: > > > On 12 Apr 2016, at 20:47, George Kadianakis <desnacked@xxxxxxxxxx> wrote: > > > > David Goulet <dgoulet@xxxxxxxxx> writes: > > > >> [ text/plain ] > >> On 11 Apr (14:42:02), George Kadianakis wrote: > >>> David Goulet <dgoulet@xxxxxxxxx> 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> > > > >> 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? > > Do we intend to change the shared random value schedule if we change these parameters, > or do we just have them for hidden services? > > If we just have them for hidden services, then it's ok to hard-code them. They would affect client and service if they change. I can't see really why we would like to change those values in the future tbh apart from design bugs we don't know about... It's cheap to give us the ability to do so though since those shared random values affect the whole HS subsystems but also I'm sure will be used by third part for whatever use case. > > > > >>> > >>>>> <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 behaviour. > > Fingerprintability. > > See which services upload their descriptors when an intro point dies. Yeah... actually making RendPostPeriod configurable by operators in the first place seems to me a bad idea now that I think of it... (see my last email about this). > > > > >>> > >>> 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. > > Again, fingerprintability. > If a service has a non-default lifetime, then it's easy to find. It leaks information about the HS... again see previous email. I might not bee too fan of adding this afterall. Cheers! David > > Tim > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP 968F094B > ricochet:ekmygaiu4rzgsk6n > > > > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev