[tor-dev] Notes from 1st Tor proposal reading group [prop241, prop247, prop259]

[George Kadianakis <desnacked@xxxxxxxxxx>]

Today was the first Tor proposal reading group [0] and we discussed the
following guard proposals:

       Prop#241: Resisting guard-turnover attacks [DRAFT]
       Prop#259: New Guard Selection Behaviour [DRAFT]
       Prop#247: Defending Against Guard Discovery Attacks using Vanguards [DRAFT]

In this mail, I will assume that the reader is familiar with the concepts
behind those proposals.

We started by discussing prop241 and prop259. These proposals specify how Tor
should pick and use entry guards.

- We decided that we should merge the remaining ideas of prop241 into prop259.

- prop259: The original guardset should also include 80/443 bridges (shouldn't
  have disjoint utopic/dystopic guard sets). We should specify a behavior on
  how the fascist firewall heuristic should work.

- prop259: Should probably not impose a specific data structure to the
  implementor except if strictly required. Instead maybe state the properties
  that such a data structure needs. Maybe we can put the hashring idea in the
  appendix?

- We can simulate the various algorithms we are examining to test their
  behavior and correctness.  Nick and Isis have already written some guard
  switching code to be simulated: https://github.com/isislovecruft/guardsim.git

  However, no simulations happen right now. We should code some simulation
  scenarios and check that the algorithm works as intended in all possible edge
  cases: https://github.com/isislovecruft/guardsim/blob/master/doc/stuff-to-test.txt

We then moved to discussing prop247. Proposal 247 specifies how entry guards
should be used by hidden services to avoid various attacks:

- We can think of prop241 as the proposal specifying how entry guards work on
  Tor. It specifies how Tor selects its set of guards and also how it picks and
  switches between them.

  Then prop247 could be stacked on top of prop241 specifying how entry guards
  are used specifically in _hidden services_ and describing how the guardsets
  from prop241 can be used in the hidden services setting.

  To achieve this design we should figure out what we need from Tor guardsets
  to achieve all the needs of prop247, and then we should design the interface
  of guardsets appropriately in prop241.

  A stupid Guardset interface that prop247 could use could be:
    guardset_layer_1 = Guardset(nodes_to_consider, n_guards=1, rotation_period_max, flags, exclude_nodes)
    guardset_layer_2 = Guardset(nodes_to_consider, n_guards=4, rotation_period_max, flags, exclude_nodes=guardset_layer_1)

- We discussed how the HS path selection should happen in prop247.

  Should layer-2 and layer-3 vanguards be picked from the set of Guard nodes,
  or should they be middle relays? This is important to figure out both for
  security and performance!

  Also, it's clear that layer-2 vanguards should not be the same node as the
  layer-1 guard. But what about layer-3 vanguards? Can they be the same node as
  the layer-1 guard? If not, then an attacker learns information about the
  layer-1 guard by keeping track of the list of layer-3 vanguards by monitoring
  many layer-3 rotations.

  Also, should layer-3 guardsets share nodes between them or should they be
  disjoint?

  We should be very careful about what kind of relays we allow in each position
  since it's clear that it has security implications. We should edit the
  proposal and specify this further.

- We should test our design here with a txtorcon test client, and get some
  assurance about the performance and correctness of the system. Also, we need
  to see how CBT interacts with it.

If you want to help with any of the above, show up for the little-t-tor meeting
tomorrow.

---

[0]:  https://lists.torproject.org/pipermail/tor-dev/2016-January/010219.html
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev