[tor-dev] Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points

Wed Jan 13 20:42:20 UTC 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

I am not a big fan of prop 246. I don't have a mindblowing counter
argument that it's bad in some way, but I don't like the tradeoffs vs
benefits ratio so much. It is a small performance improvement indeed,
so clients will not cache descriptors and have to create 1 circuit
instead of 2 before the rendezvous circuit but I don't think this is a
big problem anyway. Hidden service servers use circuits to publish
their descriptors to the corresponding HSDirs and close them without
having to do it again too soon if nothing changes and also keep the
circuits to the introduction points alive for a random number of
INTRODUCE2 cells or amount of time, again not having to create new
ones very soon.

Proposal 250 is a major step forward in making HSDirs less dangerous
and eliminates some attacks. I am super happy we have it ready that fast.

I am also slightly uncomfortable that under prop 246 I must keep open
a long lived circuit to relays not of my choice (merged HSDir + IP
decided network wide based on shared randomness value). And I have to
do it regardless how many INTRODUCE2 cells I get through them and for
a mostly fixed amount of time.

This is also a bullet in the head for hidden service popularity leaks
if the HSDir+IP can identify the service (knows the unblinded key). A
merged HSDir + IP knows the popularity of a hidden service with a very
low error margin in this case (say $LEARNED_POPULARITY * 6 =
$POPULARITY). In current design introduction points see a random
number of INTRODUCE cells from 16k to 32k. Obviously a spying
introduction point can assume that a hidden service is popular if it
received 18000 introductions in 2 hours for example... but it's a
difference between assuming something with a somewhat error margin and
having some very precise figures.

Load balancing is also a problem. Without prop 246 load balancing is
shared, the HSDirs serve the descriptors and other relays act as
introduction points (and are rotated), but will the same set of relays
be able to handle both of these (and not just for one hidden service,
but for multiple at the same time)? The amount of traffic experienced
by introduction points is significantly bigger than the amount of
traffic experienced by HSDirs given one hidden service (noticed this
back when we tested onionbalance) so rotating introduction points as
we currently do is a sane thing to do from this point of view. True
that we have some amazing weighted hash ring suggestions, but
concentrating too much information and traffic into highest bandwidth
relays in the network doesn't sound attractive because as we an
attacker doesn't need to physically seize a relay for some attacks to
work - he can just watch upstream for some traffic correlations
attacks to work.

Being able to tweak the number of introduction points at hidden
service server side is helpful for increasing capacity and load
balancing. Disabling this option will cause problems in the future,
because a network wide param setting the introduction points for all
hidden services regardless their popularity or need doesn't sound
attractive.

After prop 250, a malicious HSDir can not do so much, but a merged
HSDir + IP can for example kill the circuit and force the hidden
service to rebuild it. Under the current design, we retry for some
times and give up if an introduction point is unreliable, but with 246
we have to retry much more. If the same attacker also holds a
reasonable % of middle bandwidth fraction in the Tor network, it will
at least perform a successful guard discovery over the hidden service
which is terrible. This may be fixed by not retrying a HSDir+IP too
many times as described in section 4.3 of the proposal, but it will
automatically lead to a capacity decrease (we have 5 HSDir + IP left
out of 6).

All these might not mean too much, but I am inclined to say prop 246
doesn't offer us too many benefits. I do like it very much that prop
246 will make clients to stop caching descriptors and hidden services
be dependent on less relays overall - I am only double thinking if
it's worth it or not.

Looking forward to read comments from others as well. Thanks!

On 1/13/2016 6:50 PM, George Kadianakis wrote:
> Hello there,
> 
> we recently finished implementing proposal 250 which is one of the
> first steps for the upcoming hidden service redesign [1]. The next
> steps are implementing proposal 224 and the other performance and
> security proposals [2].
> 
> On this note, one of the open design issues that we need to tackle
> next is whether we should do proposal 246 or not. Proposal 246
> merges HSDirs and Intro Points into a single entity to simplify the
> protocol and improve its performance. The idea is that HSes will
> pick their intro points using the hash ring algorithm currently
> used for picking HSDirs. Clients will do the same and connect
> directly to the intro points instead of going through the HSDir
> step.
> 
> I suggest you read the proposal and the discussion thread to become
> better informed about this idea: 
> https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html
>
>  Proposal 246 changes the hidden service protocol substantially,
> which is why we need to decide whether to do it soon. The next
> steps in our implementation plan heavily depend on whether we will
> do proposal 246 or not.
> 
> Here are some issues that make this proposal not an obvious pick:
> 
> 1) Security issues
> 
> - Professor Hopper pointed out [3] that this proposal will double
> the number of introduction points of a hidden service (from the
> current 3 to 6). Introduction points have slightly more attack
> vectors than HSDirs, so we should not increase their number without
> analyzing further.
> 
> That said we could potentially increase the number of intro points
> by doing proposal 246, and at the same time we could also increase
> their lifetime period to multiple days (instead of the current
> 18-24 hours lifetime), to keep the exposure of hidden services to
> an acceptable value.
> 
> - It was also pointed out that the HSDir algorithm does not take
> into account the bandwidth of the nodes, making it easier to launch
> Sybil attacks.  However, the rest of the the mailing list thread
> suggests various ways to do bandwidth weighted hash ring selections
> [4], so this might not be an important factor.
> 
> 3) Load balancing issue
> 
> - With proposal 246, the Tor network decides which relays will be
> used as the introduction points of a hidden service. A hidden
> service cannot pick its own introduction points, similarly to how
> currently a hidden service cannot pick its own HSDirs.
> 
> This is a problem because it blocks load balancing solutions like 
> onionbalance from working. Variants of the onionbalance logic can
> still work as suggested in the proposal [5], at the cost of
> increased engineering and sysadmin complexity.
> 
> - Another concern here is that hidden services would not be able to
> change the number of their introduction points. This is not a big
> problem currently, but it could become in the future if the network
> gets more overloaded. As a partial solution to this, #17690
> suggests making the number of HSDirs a network-wide consensus
> parameter that could also be used by proposal 246.
> 
> 2) Reachability issue
> 
> A final issue here is that if the relay churn of the network
> increases, the introduction point hash ring might be changing
> rapidly and clients might get pointed to the wrong introduction
> points.
> 
> However, this does not seem like a greater problem than what hidden
> services are facing with HSDir reachability currently. Is this
> right, or does prop246 makes it worse?
> 
> Personally, I'm not that concerned about the security issues I
> outlined above. I think the security difference will not be that
> great, and maybe we can equalize it by using some of the listed
> solutions. However, more thinking is required.
> 
> I'm currently more concerned about the load balancing and
> reachability issues that I outlined above and maybe others that I
> forget. I would like to have more assurance that relay churn will
> not cause reachability issues to the proposal 246 system before we
> commit to it.
> 
> Feedback is very welcome. Also please post any issues that I forgot
> to mention.
> 
> We should try to figure out what to do here as soon as possible.
> 
> If we fail to come to a conclusion here, our engineering plan is to
> ignore proposal 246 and continue with proposal 224 like it never
> happened. Of course this will suck if we later decide that proposal
> 246 was super important and should have happened.
> 
> Cheers!
> 
> [1]:
> https://lists.torproject.org/pipermail/tor-dev/2016-January/010182.html
>
> 
[2]: https://lists.torproject.org/pipermail/tor-dev/2015-October/009762.html
> [3]:
> https://lists.torproject.org/pipermail/tor-dev/2015-July/009093.html
>
> 
[4]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009163.html
> [5]:
> https://gitweb.torproject.org/torspec.git/tree/proposals/246-merge-hsdir-and-intro.txt#n227
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWlrasAAoJEIN/pSyBJlsRTyEH/3jE+B+IN1AJr/w8aaRKdJST
zG1t6dlPeSMljD+UoIoXWEaTluNmWgAEEZ83FxbSluHOM+C0EuUDHa6MgY2P5uqP
XEVRbcXbYI9YpP6LHlqB+T93FJ4e0eFv8eDI+wTHI+nWeXFrGhVMJqWkbuNFqBlK
LyxVaJBerKHa3C8Oeq/++fQeDr+9254pMpsto89yAo71+capIH26nyu0Jmm2UaCt
Gwm3D8Gq4/vld8qEcwnl8dglg4t3wPlOboaSnOmp0FP4XZ9lXfGFCzTdCpYGC0MV
Zb62pO4OXFtzyM+Z5K0EUN2WSop/SFtFOiDghB42hjS9gN6P89ccQB8Q0lcZe+U=
=96nK
-----END PGP SIGNATURE-----