Hi George, George Kadianakis wrote: > Hello s7r, > > and thanks for helping with this and approaching it from a different > direction. > > Personally, I'd be really surprised if any solution that statistically > marks relays or paths as "suspicious" will ever work for this particular > problem. That's because the adversary does not need that many paths to > succeed, and also because the adversary has lots of time to carry out > the attack. I also dislike these solutions since the HS operator cannot > really distinguish between an actual attack that just happened, or their > HS getting slashdotted, or someone trolling them by connecting a > thousand times. > > Furthermore, I don't understand why your proposal marks rendezvous > points as suspicious, and not the paths themselves. After all, the > attacker can choose a diffferent rendezvous point everytime, as long as > the HS makes fresh circuits for each one. > > Also if you are suggesting the reuse of hops 2 and 3 for multiple > circuits, you are basically suggesting a layered guard approach which is > what prop247 also tries to do, and FWIW it's not simple at all > (especially from an engineering perspective). > This should be invisible for the HS operator. It should not be noticed. Trolling with a HS is something which happens now also, and we cannot stop, if that HS is accessible to the world. If someone will troll, worst case it hits the limit for some (or many) RPs in the consensus, and makes the HS server use static hop 2 and hop 3 for a random period of time, which is exactly what vanguards does except it does it by default under any circumstances and with all the RPs, not just the suspicious ones. There should be no tradeoff here. If the attacker doesn't control the RP, he should not be able to learn hop 3 (unless we are talking about adversaries that are able to watch a huge part of the network at the same time, which is a different attack harder to mitigate) which is why this protection assumes the RP is evil and defends against it by making it hard to learn hop 3 and hop 2, directly leading to making it very hard to learn the HS server Guard. I am not suggesting to reuse hop 2 and hop 3 for multiple circuits, only for rend circuits with a suspicious RP point. If we have more suspicious RP points at the same time, we have different hop 2 and hop 3 for each, for a random period of time (Please see my previous longer email sent in reply to teor for something more clear). I understand this might not be simple at all from engineering perspective. I only wanted to discuss it in depth so that we can decide if it's worth it, if it brings us more benefits than tradeoffs. If we decide it's not worth it, we'll move on with the vanguards proposal and brainstorm for a good selection logic that load balances properly. Either way, there are ways we can do HS guard discovery harder and more expensive for attackers, and we'll surely do it! Thanks for the time! Always a pleasure.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev