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

[Tim Wilson-Brown - teor <teor2345@xxxxxxxxx>]

Hi,

I also have concerns about proposal 246, I don't think its benefits are compelling

compared with the number of drawbacks.

If we do want to skip the introduction point, proposal 252 (single onion services)

provides a way for onion services to do this on an opt-in basis. (However, it doesn't

allow onion services to skip the introduction point step and stay location-hidden.)

There's also nothing preventing us from making this change in future, by modifying

how hidden services select their introduction points. We could then teach clients

to use the HSDir as an introduction point if it's in the list.

On 14 Jan 2016, at 03:50, George Kadianakis <desnacked@xxxxxxxxxx> wrote:

Hello there,
...
Here are some issues that make this proposal not an obvious pick:

1) Security issues
...
  - 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.

As far as I recall, there was no guarantee that a large hidden service would

not pick 6 low-bandwidth HSDirs/IPs for a day, with serious impact on the

reachability of that hidden service for that period.

3) Load balancing issue
...
  - 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.

It could also become a big problem for large hidden services which benefit from

10 (or more) introduction points.

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?

Proposal 246 makes it worse, because now both HSDirs and introductions depend

on a potentially churning hash ring. If churn makes an introduction point

unreachable, this increases the load on the other introduction points.

Clients also cache descriptors from HSDirs, but they need an introduction point

to be up whenever they contact the hidden service.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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