[tor-dev] Setting NumEntryGuards=2

[Florentin Rochet]

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180321/34db01ce/attachment.html>