|
Hello, Thank you for this great summary :) On 2018-03-20 04:57, Mike Perry wrote:
<skip> Arguments for staying with just one guard: 1. One guard means less observability. As Roger put it in the above blog post: "I think the analysis of the network-level adversary in Aaron's paper is the strongest argument for restricting the variety of Internet paths that traffic takes between the Tor client and the Tor network." http://freehaven.net/anonbib/#ccs2013-usersrouted Regarding the question of observability, I would take the opportunity to point out that we have a proposal discussing that question on the mailing list, which changes the bandwidth-weights equations and constraints to achieve a balanced network with an adversary considered in the process (which is not currently). Prop: https://github.com/frochet/wf_proposal/blob/master/waterfilling-balancing-with-max-diversity.txt Paper: https://www.freehaven.net/anonbib/#waterfilling-pets2017 This is somewhat linked to this "what would be a good number of entry guards" question since applying our technique increases path diversity (at network-wide scale, for whatever adversary type chosen), and reduces the efficiency of the hoovering adversary model trying to get as much as he can. This would argue is favor of 2 entry guards, because the situation is not as bad as we think. From discussion I had with Aaron at the meeting, it clearly appears that the scheme needs also some IP prefix limits to avoid worst-case scenarios if this technique is used against a relay-adversary model (but again, nothing prevents us to use it against other threat models). So, a bit of work remains but not that much. <skip> Furthermore, I believe that conflux will also be useful against traffic analysis and congestion attacks. Since the load balancing is dynamic and hard to predict by an external observer, traffic correlation and website traffic fingerprinting attacks will become harder, because the adversary can no longer be sure what percentage of the traffic they have seen (depending on their position and other potential concurrent activity). Similarly, it should also help dampen congestion attacks, since traffic will automatically shift away from a congested guard. I am really enthusiast about multipath, either at the Tor level or even at the transport level: we discussed QUIC at the meeting, but MultipathQUIC could also be a long-term option now that we discuss more than 1 entry guard. However, I would argue that it does not really help against traffic correlation. Our paper at pets18 exploits Tor's forward compatibility feature to design silent cheap, almost instantaneous and perfect active traffic confirmation that does not care about user traffic to succeed. See Section 5, https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf Maybe the real debate would be to discuss what's the major threat between active/passive attackers, and what do we care about? The question is, why should we care about hardening passive attacker's work when the active form is always as easy? For website fingerprinting, it does seem to be interesting if the attack cannot link the two paths :) Anyway, I believe the 2 guards's benefit outweighs the inconvenience, especially if we also integrate ideas such as Waterfilling :) Best, Florentin
|
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev