[tor-dev] Notes from 1st Tor proposal reading group [prop241, prop247, prop259]
desnacked at riseup.net
Tue Jan 19 20:41:23 UTC 2016
Today was the first Tor proposal reading group  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
- 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
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
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
More information about the tor-dev