[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Notes from 1st Tor proposal reading group [prop241, prop247, prop259]
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@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