Post by George KadianakisHello 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.
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.
I have not thought hard about what to do about nodes that leave the
consensus while they are still in our vanguard sets and rejoin later. I
am thinking that the simplest situation is to just pick a new node to
replace them and not worry about it.
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?
Post by George KadianakisI 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).
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.
In terms of pre-building and cannibalization
(https://bugs.torproject.org/23101), for vanguard-enabled clients, I am
going with the plan to create a special HS_GENERAL pre-built circuit
set. HS_GENERAL circuits will be four hops long (3 vanguards plus a
random middle), and will be used for all vanguard circuits except for
service-side INTRO circuits (since those are already long-lived and
pre-built, and don't need the extra middle). I have an implementation of
this and have tested it lightly -- it seems to work.
One additional wrinkle is that we will need to reverse our path
selection order, so that we do not leak information about earlier
vanguards to later hops in the path. This is
https://bugs.torproject.org/24487. For now, so I can have more of an
apples-to-apples comparison in terms of vanguard set sizes, I simply
allow the same vanguard to appear in multiple positions in the circuit,
if the prototype is enabled. I do hope to get #24487 done for 0.3.3,
though.
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.
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..
--
Mike Perry