Tim Wilson-Brown - teor teor2345@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@riseup.net wrote:
Hello there, ... Here are some issues that make this proposal not an obvious pick:
- 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.
- 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.
- 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.