Paul and others: Here is the meetbot log from the meeting: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-01-19-16.03.log.html George and I also discussed RP and IP usage after the meeting as well. I will be updating Prop#247 with that discussion. I'll send a link when I'm done. I may also work on txtorcon mockup of Prop#247 for testing, but this may prove difficult due to control port limitations. Isis will updating prop#259. We also generally agreed on merging #241 and #259, but I don't think anyone took that specific action item. Nick offered to file tickets, though. More replies below. Paul Syverson: > 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.) Nick is sending the proposal review mails to this list. For the current schedule, see: https://lists.torproject.org/pipermail/tor-dev/2016-January/010219.html The Tor meeting tomorrow is at 1330 UTC (==0830 am eastern). The agenda is ticket dev progress updates, and then discussion. If you have comments on the proposal updates, you can jump in during the discussion. > 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 > > tor-dev@xxxxxxxxxxxxxxxxxxxx > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- 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