[tor-dev] Rebooting work on proposal #247 (guard discovery)

George Kadianakis desnacked at riseup.net
Wed Dec 6 13:33:33 UTC 2017

Mike Perry <mikeperry at torproject.org> writes:

> George Kadianakis:
>> Hello Mike,
>> I'm finally getting out of the prop224/microdescriptor bug pile, and
>> getting more time to start working on guard stuff like prop247 again.
>> I'm planning to spend a few days next week to regain knowledge on
>> prop247. I'll check out the notes from the Wilmington hackfest, re-read
>> my old simulator's code, etc.

Hey, and thanks for the reply!

> I was not involved in with Prop271, so I am not deeply familiar with it.
> However, it has several things we do not need. In particular, the plan
> for prop247 still is to treat consensus information as the official
> notion of vanguard reachability, so there is no need to try to determine
> censorship, firewall, or local network reachability information. If a
> node is in the consensus, it stays in our vanguard set and does not get
> replaced until it actually leaves the consensus. This is consistent with
> how the consensus is currently used for interior hops, and mitigates
> path bias attacks.
> If it is dead-simple to use only the consensus uptime portions of
> prop271 without the reachability code, I could be convinced of that. But
> as it is, the rotation times do not need to be as long as guards, and
> the implementation simplification here is attractive. Plus, nodes that
> fall completely out of the consensus periodically like this are probably
> bad choices anyway..
> What do you think?

Sounds plausible.

I'm slightly worried that not tracking transient reachability status
might cause situations where all the L2 guards are temporarily down and
hence brings complete the service/client to complete halt. I'm not sure
how likely this is to happen, and it surely depends on L2 size and L2
node selection parameters.

I have not thought about the engineering aspects of this. I think
bending the prop271 code to do this might be a PITA. But I'm also not
sure if not using the guard layer is gonna be easier either. I imagine
there will be engineering complexities either way here. Will try to
figure this out in the coming weeks.

>> I know you have thought more about prop247 the past months, and it would
>> be great if you could brief me up on any updates that I should know
>> about. Specifically I'm wondering if you have any new insights on how
>> the proposed prop247 changes interact with Tor's guard algorithm (prop271)?
>> Also any other things I should know about from your work on the
>> performance simulator? Perhaps ideas about performance, topology or path
>> restrictions?
> Yes. I have decided to simplify everything as much as possible. I am
> going with a mesh topology for the prop247 performance tests (via
> https://bugs.torproject.org/13837,  https://bugs.torproject.org/23101
> and https://bugs.torproject.org/24487). That is the simplest option to
> implement and test for performance, and intuitively seems to have
> almost as good security properties as the bin version (unless your
> security simulator tells us otherwise).

Sounds reasonable!

> I am also aiming for these high-level design goals, most important
> first:
> 0. All service-side circuits use 3 hops of vanguards.
> 1. Hidden services should avoid trivially disclosing their third
>    vanguard to a non-network adversary (ie one that is not running nodes
>    but that is watching either HSDESCS or connecting to the service).
>    This means their paths look like this:
>    S - G - L2 - L3 - HSDIR
>    S - G - L2 - L3 - Intro
>    S - G - L2 - L3 - M - Rend
> 2. Clients should avoid revealing their third vanguard hop to services
>    and to nodes that have information about which service they are
>    accessing. This means that their paths look like this:
>    C - G - L2 - L3 - M - HSDIR
>    C - G - L2 - L3 - M - Intro
>    C - G - L2 - L3 - Rend
> 3. Clients use 3 hops of vanguards for all hidden service circuits.
> If we do all of these, it will mean that we will have long path lengths
> (8 hop rends), but it also means that it is easy to reason about
> linkability and information disclosure. My thinking is that we should do
> the performance tests with the safest option first (ie: all of these
> goals), and see exactly how bad it is, and then make compromises if it
> turns out to be much worse performance than status quo.
> In the event of bad performance, I would alter property #3 before
> messing with property #2, and alter #2 before property #1, but I could
> be talked into a different strategy, or driven to one based on data.

Sounds reasonable.

In general, I imagine that this feature is gonna be opt-in initially
which makes me worry less about performance in the beginning.

Also, I'm currently not too afraid of guard discovery attacks for the
client-side, which might mean that we can let the vanguard feature as
optional for much longer time for clients (bringing the hop count to 7).
> I have not written up the set of performance experiments I intend to run
> yet, but at a high level I want to measure two things for a few
> different L2 and L3 guard set sizes:
> A. How does the average performance compare to existing onionperf data
>    at https://metrics.torproject.org/torperf.html?
> B. What is that variance over time in performance with a fixed entry
>    guard, as the L2 and L3 guards rotate? Is the variance measurably
>    different than what happens on onionperf?
> #A here will tell us if our paths are too long and seriously impact
> average performance, meaning we have to revisit goals #0-3.
> #B will tell us how much a really bad L2 or L3 set can impact
> performance, and how often that happens. I expect that as we increase L2
> and L3 sizes, variance in performance will go down, until we hit
> diminishing returns. The goal is to find that sweet spot for choosing L2
> and L3 as small as possible for as little variance as possible.
> It would be great if your security simulator can tell us which L2 and L3
> values are worth considering, so I can gather more useful (and more
> detailed) performance data with fewer experiments.

ACK. Will be working on this.

> I think that is it for now. As far as implementation goes, I am doing my
> best to keep
> https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorV up
> to date and stick with that timetable.
> This means I want to merge all of the torrc options needed for the
> performance tests into 0.3.3 (by mid January), so that hidden
> service operators have the option of using the performance test
> controller to get vanguard behavior if they want. My assumption here is
> that we basically can all agree on the high level approach, and all
> agree it is an improvement over status quo, but we will want the extra
> time to actually make specific parameter choices and decide if we need
> to or want to live with shorter paths for some scenarios..

Makes sense.

More information about the tor-dev mailing list