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

[George Kadianakis]

Mike Perry  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.
> 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.)
> 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.
>
> 
>
> Concrete things we can do now:
> #1: ourselves set those guard params to 2 and find bugs. once #3 below is 
> done, encourage others, like on tor-talk, to do it too.
> #2: enumerate the current situations where we use a guard other than our 
> first guard, especially noting the ones where the attacker can make us use a 
> guard other than our first guard. fix as many as we want to fix. maybe 
> categorize by whether they cause us to mark our first guard as down or not.

OK, I did a bit of #2 yesterday as part of an IRC discussion with Mike
and Roger. In particular, I attempted to enumerate the places in our
codebase where we mark a guard as unreachable and hence skip it for
future circuits.

The key functions here are entry_guard_failed() and entry_guard_chan_failed().
These are called in the following places:

1) circuit_build_failed(): We blame the guard if there was an error
   during path building when we don't have the first hop open on the
   circuit yet. We don't blame the guard for errors during path
   selection.

2) connection_dir_request_failed(): We blame the guard if we fail to
   connect to a dirserver because of network error.

3) connection_or_about_to_close(): We blame the guard when we are
   closing an OR connection that started at us but never made it to
   state open. We do this because otherwise we would keep beating our
   heads against a broken guard.

4) connection_or_client_learned_peer_id(): We blame the guard when we
   receive the wrong RSA identity key from the guard during the TLS handshake.

The first 3 cases here seem to handle the cases of network errors and
unreachable guards. It's interesting how we have to handle this case in
three different places. I wonder if we are missing any other places here.

The last case seems to handle the case of network MITM attacks. I don't
see anything wrong with that, since encountering an MITM certainly means
that something bad is going on, and also an MITM adversary could also
cause one of the first 3 cases.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[George Kadianakis]

Mike Perry  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! :)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Mike Perry]

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.
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.)
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.

The full meeting logs are here:
http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-04-18-17.01.log.html

Our notes from the pad (https://pad.riseup.net/p/TwoGuardMeeting) are
also below, for archival. Please comment further here on list or in the
testing ticket, not on the pad. It will disappear eventually (and/or get
edited by randos). Please pay particular attention to the proposal
variants we have below, and weigh in if you like (especially with
adversary differentiation).

===

Things to decide:
1. Remove some or all of Tor's path restrictions?
   1a. Remove some,  for some hops? (Allow just same node, or same /16 + 
family two? and for which hops?)
   1b. Remove all?
   1c. 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. Use two guards?
   2a. Set prop#271 values?
   2b. Modify prop#271 behavior?
   2c. Two directory guards?
3. Alternatives?
3a. Allow some leakage about the guard, such as dividing guards 
into sets sharing similar /16 and family restrictions and then choosing exits 
and middles in a way that violates no path restrictions for any guard in your 
set. Taken to the extreme, we get the radical solution of two Tors: A-Tor and 
B-Tor. A-Tor exits, middles, and guards don't conflict each other, and similary 
for B-Tor. Alternately, we can just enforce that no exit is in the same /16 or 
family as any guard.


Reasons for 1:
1. Eliminates cases where adversary gets to influence your guard choice
2. Doing 1b also makes vanguard implementation simpler (no risk of choosing 
an impossible set of vanguards)

Blockers to 1:
1. Relay operators may like node family as protection?
2. 1b would make nearly _all_ kinds of path restriction impossible, 
indefinitely.
3. Circular paths make traffic analysis easier.
4. Circular paths are scary. :/


Reasons for 2:
1. Two guards inherently more resilient to downtime/DoS than one.
2. Helps conceal transition information when adding/removing single guards
3. Conflux will help us in more ways than just performance (reliability, 
congestion/DoS resistence)

Blockers for 2:
1. Current Prop#271 options may not be what we want (what do we do when two 
guards go down?)
2. May still need to remove/relax some restrictions, to avoid using 3rd 
guard if one is down.
3. Sybil time is halved (but still large)
4. Prop#271 mishandles directory guards (but maybe in a way we want it to)
5. Two-equal-guards means 2X external observers on the path for 1/2 of 
client traffic (but more multiplexed activity)


Relevant tickets related to guard-selection/path-restriction designs:
https://trac.torproject.org/projects/tor/ticket/14917 (Original bug that 
cuased us to use a second guard)
https://trac.torproject.org/projects/tor/ticket/25347 (Clients thrash at 
one busy guard)
https://trac.torproject.org/projects/tor/ticket/13908 (one directory guard?)
https://trac.torproject.org/projects/tor/ticket/25546 (vanguard patches -- 
open children are all about restriction issues)
https://trac.torproject.org/projects/tor/ticket/25783 (prop#271 bug we 
might encounter if we switch to prop#291 (2 primaries) right now. there's 
probably more where this came from)
https://bugs.torproject.org/17773 (How to transition if guard lose guard 
flag?)
https://bugs.torproject.org/2998 (Bridge path restriction circuit failure 
bug)
Other relevant tickets:
https://trac.torproject.org/projects/tor/ticket/24309 (UX for communicating 
guard purpose / protection to user)

Roger's proposal:
* Remove /16 and family path restrictions between guard and last hop
* Optionally, dir auths don't give you Guard if you're an Exit
* Use first guard but pad to backup guard so the switch isn't as 

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

[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

The meeting will be at 17:00 UTC, on Wednesday, April 18th, in
#tor-meeting on irc.oftc.net. (That's 10:00 left coast, 12:00 middle
coast, 13:00 right coast, and 19:00 in several socialist paradises that
strangely do not have public water fountains.)
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180415T1700

Things we need to decide:
1. Do we abandon Tor's path restrictions?
2. Do we use two guards?

At the end of this meeting, we should commit to one or both of these
things long-term. (Surprise twist: we're already doing #2!)

Each of these choices is a nuanced thing. And just picking one or the
other doesn't solve everything. I think it's best to think of them as a
commitment to a plan over some timescale, based on the information we
have available today.


People who mos def should attend:
George Kadianakis,
Roger,
Nick,
Me

People who probably maybe should attend:
Aaron Johnson,
Isis (and others concerned about guard fingerprinting),
You?


-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev