Mike Perry:
> Mike Perry:
> > Heyo.
> >
> > We're going to have a meeting to discuss Proposal 291. See this thread:
> > https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html
>
> 3. Describe adversary models for our variant proposals from the notes.
> (Why do we disagree? In Mike's case, my disagreements are because I
> think each step is an improvement over previous/status quo -- we can
> decide harder things later and still do better both now and later.)
Ok, in the interest of getting closer to an adversary model, let's first
start with enumerating the properties the proposals below provide.
Properties #1-5 have parenthesis at the end of them. When the condition
in parenthesis is met for property #N, we'll call that "strong #N".
1. Hidden service use can't push you over to an unused guard (at all).
2. Hidden service use can't influence your choice of guard (at all).
3. Exits and websites can't push you over to an unused guard (at all)
4. DoS/Guard node downtime signals are rare (absent)
5. Nodes are not reused for Guard and Exit positions ("any" positions)
6. Information about the guard(s) does not leak to the website/RP (at all).
7. Relays in the same family can't be forced to correlate Exit traffic.
> Roger's proposal:
> * Remove /16 and family path restrictions between guard and last hop
> * Optionally, dir auths don't give you Guard if you're an Exit
> * Use first guard but pad to backup guard so the switch isn't as obvious
> * First and backup guard are chosen in different /16's and different families
Depending on how good the padding is, this proposal maybe-provides:
1. Hidden service use can't push you over to an unused guard (at all).
3. Exits and websites can't push you over to an unused guard (at all)
Depending on how good the detection mechanism is:
4. DoS/Guard node downtime signals are much more rare (absent)
It provides strong:
5. Nodes are not reused for Guard and Exit positions ("any" positions)
It provides:
7. Relays in the same family can't be forced to correlate Exit traffic.
It does not provide:
2. Hidden service use can't influence your choice of guard (at all).
6. Information about the guard(s) does not leak to the website/RP (at all).
> asn proposal:
> * Allow "same node, same /16, same family" between guard and last hop. If it's a 3-hop circ (A - B - A), extend it to a 4-hop circ (A - B - C - A).
> * Switch to two primary guards; and revisit prop#271 as needed to make this possible and good.
This proposal provides strong:
1. Hidden service use can't push you over to an unused guard (at all).
2. Hidden service use can't influence your choice of guard (at all).
3. Exits and websites can't push you over to an unused guard (at all)
If we fix prop#271's downtime detection for the two primaries, it provides:
4. DoS/Guard node downtime signals are rare (absent)
If the client chooses its primary guards from the same /16 or family, it
does not provide #6 (since the hop before the RP won't ever be in that
family):
6. Information about the guard(s) does not leak to the website/RP (at all).
It does not provide:
5. Nodes are not reused for Guard and Exit positions ("any" positions)
7. Relays in the same family can't be forced to correlate Exit traffic.
> Nick's proposal:
> * allow two primary guards
> * tweak guard design so that primary guards are not chosen in same /16 or family
> * separately, consider relaxing path restriction rules. Not removing.
> * separately, consider other proposals for new behavior on guard failure (as modification to guard-spec).
> * separately, consider requiring introduce cells to contain >=two possible rendezvous points in separate families.
> * separately, require that introduction points be chosen from different families.
In the short term, this proposal provides #1,3-4,6 (not strong, because
if one of the primary guards is down, you can be forced into using a
third):
1. Hidden service use can't push you over to an unused guard (at all).
3. Exits and websites can't push you over to an unused guard (at all)
4. DoS/Guard node downtime signals are rare (absent)
6. Information about the guard(s) does not leak to the website/RP (at all).
In the short term, it gets strong #5 and #7, though this may change if
we relax restrictions.
5. Nodes are not reused for Guard and Exit positions ("any" positions)
7. Relays in the same family can't be forced to correlate Exit traffic.
Changing the introduce cell will provide strong #1-2. Improving guard
failure conditions gets it strong #4:
1. Hidden service use can't push you over to an unused guard (at all).
2. Hidden service use can't influence your choice of guard (at all).
4. DoS/Guard node downtime signals are rare (absent)
> Aaron's proposal:
> * Use first guard but pad to backup guard so the switch isn't as obvious
> * First and backup guard are chosen in different /16's and different families
Depending on how good the padding is, this proposal maybe-provides:
1. Hidden service use can't push you over to an unused guard (at all).
3. Exits and websites can't push you over to an unused guard (at all)
Depending on how good the detection mechanism is:
4. DoS/Guard node downtime signals are much more rare (absent)
It provides strong #5:
5. Nodes are not reused for Guard and Exit positions ("any" positions)
It provides #7:
7. Relays in the same family can't be forced to correlate Exit traffic.
It does not provide #2 or #6:
2. Hidden service use can't influence your choice of guard (at all).
6. Information about the guard(s) does not leak to the website/RP (at all).
> Mike's proposal from the meeting:
> * Set "num primary guards"=2 and "num primary guards to use"=2
> * Make no other changes right now
> * File a path selection parent ticket to decide/fix path selection issues
> * Tweak prop#271 behavior when both guards are down
> * Investigate either favor-one-guard preference, conflux, and/or padding, but do this carefully.
In the short term, this proposal provides #1,3-4,6 (not strong, because if
one of the primary guards is down, you can be forced into using a
third):
1. Hidden service use can't push you over to an unused guard (at all).
3. Exits and websites can't push you over to an unused guard (at all)
4. DoS/Guard node downtime signals are rare (absent)
6. Information about the guard(s) does not leak to the website/RP (at all).
If you get unlucky and choose both primaries from the same /16 or
family, you also lose #1,3,6.
In the short term, it gets strong #5 and #7, though this may
change if we relax restrictions:
5. Nodes are not reused for Guard and Exit positions ("any" positions)
7. Relays in the same family can't be forced to correlate Exit traffic.
Improving guard failure conditions gets it strong #4:
4. DoS/Guard node downtime signals are rare (absent)
It does not provide:
2. Hidden service use can't influence your choice of guard (at all).
> [Mike's rules proposal to Roger in the other thread]
> In the world where we keep path restrictions, these would be my rules:
> 1. Two equal guards, chosen from not the same /16 or family
> 2. Choose each vanguard layer members such that each layer has at least
> one node from a unique /16 and family.
> 3. Build paths in a strict order, from last hop towards guard. If you
> can't build a path with this ordering, start over with a sampled guard.
> (With rule #1 and #2, this should be very rare and should mean that
> a guard is marked down locally but still marked up in the consensus.)
> 4. No guards as exits (Not needed but do it anyway for other reasons).
>
> Then under these rules, you decide to use a new primary guard, if:
> 0. When a guard leaves the consensus, replace it with a new primary
> guard.
> 1. Temporarily pick a new guard when your two primaries are locally down
> or unusable (ie step #3 above fails).
This gets #1 and #6, but not strong (if one guard is temporarily down):
1. Hidden service use can't push you over to an unused guard (at all).
6. Information about the guard(s) does not leak to the website/RP (at all).
It gets strong #3-5:
3. Exits and websites can't push you over to an unused guard (at all)
4. DoS/Guard node downtime signals are rare (absent)
5. Nodes are not reused for Guard and Exit positions ("any" positions)
It does not provide:
2. Hidden service use can't influence your choice of guard (at all).
======================================================================
Ok, so here's a proposal that gets strong #1-4, and regular #5-7. It is
my current favorite:
> * Set "num primary guards"=2 and "num primary guards to use"=2
> * Don't give Exit nodes the Guard flag.
> * Allow "same node, same /16, same family" between guard and last hop,
> but only for HS circuits (which are at least 4 hops long for these
> cases).
> * Allow same /16 and same family for HS circuits.
> * When a primary guard leaves the consensus, pick a new one.
> * If both primary guards are down/not completing circuits, pick a new one.
Strong:
1. Hidden service use can't push you over to an unused guard (at all).
2. Hidden service use can't influence your choice of guard (at all).
3. Exits and websites can't push you over to an unused guard (at all)
4. DoS/Guard node downtime signals are rare (absent)
Regular:
5. Nodes are not reused for Guard and Exit positions ("any" positions)
6. Information about the guard(s) does not leak to the website/RP (at all).
7. Relays in the same family can't be forced to correlate Exit traffic.
It gives up on strong #5 to get strong #1 and strong #2, because I don't
see a lot of difference between an HS circuit that uses the same Guard
as the RP vs one that uses the same Guard node for one of the other
side's middle or Guard hops (which we can't prevent).
We don't get strong #6, because if one guard is temporarily down but
still in the consensus and the adversarial RP makes enough circuits fast
enough, it could theoretically notice that the next node is never the
remaining not-down Guard. This window of time can be minimized by more
eagerly switching guards when one of them is unresponsive. It could be
eliminated by using S - G - L2 - L3 - R paths with vanguards (at the
expense of directly exposing service L3 vanguards to the RP, and
creating service linkability).
--
Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev