Notes from 1st Tor proposal reading group [prop241, prop247, prop259]
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
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- Mike Perry
On 20 Jan 2016, at 07:41, George Kadianakis <desnacked@riseup.net> wrote:
- 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.
I wish I was there, but it was after midnight my time, so… I'm currently working on #17840, which adds IPv6 client support to tor using the fascist firewall checks. IPv6-only clients also have restricted guard choices, much like clients which can only use 80/443. https://trac.torproject.org/projects/tor/ticket/17840 See also #17849, where yawning and I discuss logging a warning if clients have very restricted guard choices. https://trac.torproject.org/projects/tor/ticket/17849 Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
participants (4)
-
George Kadianakis -
Mike Perry -
Paul Syverson -
Tim Wilson-Brown - teor