Tim Wilson-Brown - teor <[email protected]> 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 <[email protected]> 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. > _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
