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

Tue Jan 19 22:20:56 UTC 2016

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

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160119/fd571e62/attachment.sig>