Re: [tor-bugs] #20524 [Core Tor/Tor]: Revise initial descriptor upload behavior for onion services

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#20524: Revise initial descriptor upload behavior for onion services
-------------------------------------------------+-------------------------
 Reporter:  twim                                 |          Owner:  dgoulet
     Type:  enhancement                          |         Status:  closed
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:  fixed
 Keywords:  tor-hs, research, tor-spec, prop224  |  Actual Points:
Parent ID:  #20657                               |         Points:  0.5
 Reviewer:                                       |        Sponsor:
                                                 |  SponsorR-can
-------------------------------------------------+-------------------------
Changes (by dgoulet):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Current state of prop224 hidden service about descriptor upload.

 Service upload their descriptors (current and next for the overlap period)
 with:
 {{{
 #define HS_SERVICE_NEXT_UPLOAD_TIME_MIN (60 * 60)
 #define HS_SERVICE_NEXT_UPLOAD_TIME_MAX (120 * 60)
   desc->next_upload_time =
     (time(NULL) + crypto_rand_int_range(HS_SERVICE_NEXT_UPLOAD_TIME_MIN,
                                         HS_SERVICE_NEXT_UPLOAD_TIME_MAX));
 }}}

 Trying to answer the original questions of this ticket:

 > What is the threat model here?

 As a network observer or Guard of a tor with multiple hidden services, not
 uploading them at the same time can help hide the fact that A.onion and
 B.onion aren't necessarily on the same tor instance. Not perfect of course
 but it helps.

 > How exactly descriptors should be uploaded?

 I assume at least at a random interval that is inside the lifetime of the
 descriptor on the HSDir side which is 3 hours right now by default with
 prop224.

 > In what range delays should be set?

 The above I think answers it.

 > How this will work along with absent delays after #20082?

 At startup, the service establishes intro points and once they are set for
 a descriptor, it's immediately uploaded. So at startup, for reachability
 reasons, we upload as soon as we can. Adding any kind of random delay here
 could be really annoying for users and application type like Ricochet for
 instance.

 That being said, I'm closing the ticket so we can move on *BUT* if
 anything could be improved here or needs more clarification, I suggest we
 go through tor-dev@ for a discussion and then we can either patch the code
 or/and the spec according to the conclusions.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20524#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs