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

[George Kadianakis]

Tim Wilson-Brown - teor <teor2345 at gmail.com> writes:

> Hi,
>

Hi, thanks for the feedback.

> I also have concerns about proposal 246, I don't think its benefits are compelling
> compared with the number of drawbacks.
>

To better understand the performance benefits of prop246, here are some
experimental graphs by Karsten that show how much time each hidden service
connection substep takes: http://ec2-54-92-231-52.compute-1.amazonaws.com/

As you can see the "fetch descriptor" step (which prop246 removes) is one of
the most lengthy ones.

> 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.)
>

Yeah, SOS is not suitable for all the threat models we are trying to cover.

> 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.
>

Hm, maybe. But with increased migration and engineering costs.

>> On 14 Jan 2016, at 03:50, George Kadianakis <desnacked at riseup.net> 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.
>

Isn't that also the case for HSDirs currently?

> Clients also cache descriptors from HSDirs, but they need an introduction point
> to be up whenever they contact the hidden service.
>