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

[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.)

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev