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. > > --- > > [0]: https://lists.torproject.org/pipermail/tor-dev/2016-January/010219.html > _______________________________________________ > tor-dev mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
