Hi George,
Crap. I missed this buried at the bottom of Nick's general announcement last Thursday about reviewing Tor Proposals (which was in my big backlog of threads to get to, and I did not notice its specific relevance to guards and onion services till I saw here).
When is the next one of these (guard proposals review discussion)? Are they listed on some general schedule somewhere? I see the reference to the little t-tor meeting tomorrow. (A) when is that? (B) Is there an agenda? Will the whole thing be devoted to discussing these three proposals? (I don't know if/when I can participate given other obligations but would like to know what when will be happening.)
aloha, Paul
On Tue, Jan 19, 2016 at 10:41:23PM +0200, George Kadianakis wrote:
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.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev