#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs