[tor-dev] Proposal #291 (two guards) IRC meeting Wed Apr 18, 17:00 UTC

[George Kadianakis]

Mike Perry <mikeperry at torproject.org> writes:

> Mike Perry:
>> Heyo.
>> 
>> We're going to have a meeting to discuss Proposal 291. See this thread:
>> https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html
>
> Ok, we had this meeting. High level (ammended) action items are:
>
> 1. Use patches in https://trac.torproject.org/projects/tor/ticket/25843
>    to set NumEntryGuards=2 in torrc, and observe results. Please join us!
>    Stuff we are looking for during testing is on that ticket!
> 2. Merge that patch to make the torrc guard options do what we meant for
>    them to do. Probably backport it.

Hello,

I wrote the patch on #25843 and I'm now testing 2-guards on my Tor. So far so
good, but I think we need people on more unstable connections to test this.

> 3. Descibe adversary models for our variant proposals from the notes.
>    (Why do we disagree? In Mike's case, my disagreements are because I
>     think each step is an improvement over previous/status quo -- we can
>     decide harder things later and still do better both now and later.)

Here is my proposal, but please don't consider it set on stone. I
actually think these are really complicated issues that take a while to
understand, and we should probably not rush it. Even on a short first
IRC meeting we came up with new issues and ideas while discussing this
topic.

asn proposal:
  1) Allow "same node, same /16, same family" between guard and last hop.
     If it's a 3-hop circ (A - B - A), extend it to a 4-hop circ (A - B - C - A).
  2) Switch to two primary guards; and revisit prop#271 as needed to make this possible and good.

Rationale:

I care about an attacker who is trying to deanon Tor client by setting
up Tor nodes and comboing various active attacks. In particular, I worry
about adversary who uses guard discovery to learn client's guard nodes
and then uses #14917 or tries to DoS them.

I like two guards because it makes us stronger and more redundant
against such attacks, and also because it improves congestion. The
"pad-to-backup" idea seems too experimental to me, and not sufficiently
specified right now hence I'm unable to analyze it (e.g.  how much do we
pad, how often, can this actually mask us against adversary who launches
#14917 repeatedly?).

I propose altering the above path restrictions because that seems to be
the only way to concretely defend against #14917 (e.g. see attacks
against idle clients on meeting log, etc.). Attackers who have already
owned our guard node are not in my threat model wrt these attacks.  IMO
simple A - B - A path restrictions don't help us against such persistent
adversaries; e.g. attacker can simply spawn up another tiny relay C on
another data center and do an A - B - C correlation attack.

> 4. Agree on an order of operations for fixes+changes, ideally such that we
>    don't block forever trying to come up with a perfect solution. Things
>    are pretty bad now. All we really need to do is agree on steps to make
>    it better.
>

I think (1) and (2) above can be considered as orthogonal issues and get
done in any order. IMO, here are the prerequisites for doing these tasks:

For path restrictions: Specify current path restrictions through the whole Tor circuit
                       and write a concrete proposal with proposed changes. I think we
                       are looking for 0.3.5 if we want to do this.

For 2-guards: Get the 2-guard design sufficiently tested to ensure that we
              are not gonna bug out the whole network by switching to
              2-guards. I'm particularly worried about clients on bad
              networks, and clients continuously flapping on-and-off the net.
              If we toggle the consensus param switch soon, we should be
              prepared for another round of guard bugs in 034, and that's fine.

Cheers! :)