<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello,</p>
<p>Thank you for this great summary :)<br>
</p>
<br>
<div class="moz-cite-prefix">On 2018-03-20 04:57, Mike Perry wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20180320035718.GA1831@torproject.org">
<pre wrap=""><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."
<a class="moz-txt-link-freetext" href="http://freehaven.net/anonbib/#ccs2013-usersrouted">http://freehaven.net/anonbib/#ccs2013-usersrouted</a>
</pre>
</blockquote>
<br>
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).<br>
<br>
Prop:
<a class="moz-txt-link-freetext" href="https://github.com/frochet/wf_proposal/blob/master/waterfilling-balancing-with-max-diversity.txt">https://github.com/frochet/wf_proposal/blob/master/waterfilling-balancing-with-max-diversity.txt</a><br>
Paper: <a class="moz-txt-link-freetext" href="https://www.freehaven.net/anonbib/#waterfilling-pets2017">https://www.freehaven.net/anonbib/#waterfilling-pets2017</a><br>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:20180320035718.GA1831@torproject.org">
<pre wrap=""><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.
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
See Section 5,
<a class="moz-txt-link-freetext" href="https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf">https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf</a><br>
<br>
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?<br>
For website fingerprinting, it does seem to be interesting if the
attack cannot link the two paths :)<br>
<br>
Anyway, I believe the 2 guards's benefit outweighs the
inconvenience, especially if we also integrate ideas such as
Waterfilling :)<br>
<br>
Best,<br>
Florentin<br>
<blockquote type="cite"
cite="mid:20180320035718.GA1831@torproject.org">
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tor-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>