s7r: > On 1/24/2016 12:10 AM, Roger Dingledine wrote: > > A few more details about "this is not always enough" would be > > helpful here. In particular, is it not always enough because > > sometimes even 3 hops is not safe enough, or not always enough > > besides sometimes making a 3-hop circuit isn't what the HS wants to > > do? Or something else? > > Not enough in the sense that it can theoretically get Sybiled and end > up with at least a guard discovery attack. Since an attacker can > request unlimited circuits to an evil rendezvous point, his other evil > relays will, with enough retries, end up in the path as well. > > > > > A) Can I deny service to a hidden service by methodically > > pretending to attack it from each honest relay, one at a time, > > causing it to become upset at each of these relays? > > Only if you are the only one connecting to that hidden service and > make 5 rendezvous circuits with each relay as a rendezvous point. But > after little time the total number of rendezvous circuits will grow so > large that you'll have to exponentially have to build more rendezvous > circuits with each relay as a rendezvous point to ban them all. So > it's a whole lot of work, you'll DDoS the hidden service guard or a > lot of other things first, before hitting the limit of this protection. Can you give a more rigorous analysis of this in the proposal, perhaps with more examples/math? This seems to suggest that if someone is mounting an attack, it gets harder and harder for the detector to recognize successive malicious RPs. Something seems amiss here. > > B) Can I fool your reputation system by raising the total number > > of rendezvous attempts that I attempt, in effect making the hidden > > service feel more popular so it's not alarmed as much by any single > > rendezvous point? I could imagine ways to launch a rendezvous > > attempt that are quite cheap on the part of a client who has no > > plans to follow through. > > > Yes, you could I think. But this has costs and is also visible to the > hidden service operator. And we keep count of established rendezvous > circuits with streams inside, not failed rendezvous circuits. We only > count successes, to make it costly for an attacker. They may not be able to differentiate this from a sudden spike in interest in the service, or attention from a scraper or DDoS. I'm also curious if you intend to combine this with Rend#1, Rend#2, or some other version than the previous thread? From your writing, my guess is you want this to apply this to paths like: 4. C - L - M - R&E -- E - M - L - H (Let's call this Rend#4). Is that true? If so, I'm a bit worried about the timing attack version of the Sybil attack in that case. We're unlikely to ever want to pad all the way across the circuit, which means that an adversary doesn't have to control R&E, but merely watch for connections to their chosen non-malicious R&E *from* their malicious E. If they always chose R&E to be very low-traffic nodes, there will be a very low base rate of normal circuits from E to R&E, making it a high probability that if malicious E sees an extend from a middle M to R&E, it is in the right position in the circuit and wins the Sybil, discovering M. This makes me think that while this detector is useful for Rend#2 or Rend#4 (modulo Roger's concerns), it still doesn't allow us to abandon Rend#1 completely as a high security option. Or, at least, the proposal as written also lacks the math for us to make it comparable to Rend#1. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev