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 obvious
* First and backup guard are chosen in different /16's and different families
asn proposal:
* 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).
* Switch to two primary guards; and revisit prop#271 as needed to make this possible and good.
Nick's proposal:
* allow two primary guards
* tweak guard design so that primary guards are not chosen in same /16 or family
* separately, consider relaxing path restriction rules. Not removing.
* separately, consider other proposals for new behavior on guard failure (as modification to guard-spec).
* separately, consider requiring introduce cells to contain >=two possible rendezvous points in separate families.
* separately, require that introduction points be chosen from different families.
Aaron's proposal:
* Use first guard but pad to backup guard so the switch isn't as obvious
* First and backup guard are chosen in different /16's and different families
Mike's proposal:
* Set "num primary guards"=2 and "num primary guards to use"=2
* Make no other changes right now
* File a path selection parent ticket to decide/fix path selection issues
* Tweak prop#271 behavior when both guards are down
* Investigate either favor-one-guard preference, conflux, and/or padding, but do this carefully.
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.
#3: merge a patch to make the torrc guard options do what we meant for them to do
#4 Descibe adversary models for above proposals? (Why do we disagree? In Mike's case, my disagreements are primarily because I think ech step is an improvement over previous/status quo -- we can decide harder things later and still do better).
===================
--
Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev