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

[George Kadianakis <desnacked@xxxxxxxxxx>]

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev