Re: [tor-bugs] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for ephemeral services

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

#20082: Lower initial descriptor upload delay for ephemeral services
-------------------------------+------------------------------
 Reporter:  twim               |          Owner:
     Type:  enhancement        |         Status:  new
 Priority:  Medium             |      Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor       |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:  tor-hs, research,  |  Actual Points:
Parent ID:                     |         Points:
 Reviewer:                     |        Sponsor:  SponsorR-can
-------------------------------+------------------------------

Comment (by twim):

 Replying to [comment:3 dgoulet]:
 > So indeed... why keep a delay at all for services? Descriptor
 publication to a directory only happens once all intro points circuit are
 ready and those are established at startup. If you think about it, it's
 actually a very _specific_ pattern to detect a service startup. As a guard
 you see 5 circuits being established at once (yes we need 3 IPs but we
 launch 2 extras for better luck) then 2 of them dies quickly and you have
 a 6th circuit almost 30 seconds after the initial launch of those... I'm
 not saying that by removing that delay we'll make it go away but I really
 don't see the point of the delay here to hide anything. Thus, I'm all for
 _removing_ it unless armadev had a reason to add that delay :) 10 years
 ago :).

 Being more specific, this lower bound of 30s was introduced by commit
 b3f846b313b3cf3191e3a9a54ec1c97227393d3d which reads:
 {{{In very rare situations new hidden service descriptors were published
 earlier than 30 seconds after the last change to the service, with the 30
 seconds being the current voodoo saying that a descriptor is stable.}}}
 So I don't see any reason to trust the voodoo and thus have this delay. :)

 Also this delay makes it *more* distinguishable for a passive adversary
 (ISP) whether a client just set up an onion service or not.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20082#comment:5>
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