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