George Kadianakis:
> Mike Perry <mikeperry@xxxxxxxxxxxxxx> writes:
>
> > 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".
> >
>
> Thanks Mike for this email. I think this moves us forward quite a bit
> with an adversary model here! Here is some feedback:
>
> > 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).
>
> Can we have a bit of more detailed description about the two properties above?
> (2) seems like a superset of (1), so making these properties clear would be useful.
Yes, if a defense provides #2, then it always provides #1. Also, a
defense provides #1 without providing #2 (by using two guards equally,
for example).
Or said a different way, an attacker who can break #2 can sometimes use
that to break #1.
To avoid confusion, I don't think we should change the property wording
or numbering until we do another round of proposal comparison, and/or
until people propose new properties that some designs satisfy (or
failed to satisfy).
> > 3. Exits and websites can't push you over to an unused guard (at all)
> > 4. DoS/Guard node downtime signals are rare (absent)
>
> Also, what does property (4) mean exactly?
Property 4 is the best argument for using two guards as opposed to only
fiddling with restrictions. With the current way we handle onionskin
failure (#25347), clients will simply lose connectivity by way of
endless DESTROY responses before making a valid circuit. This means that
the adversary can onionskin-DoS guard nodes one at a time, and wait for
a hidden service to become unresponsive. That is what it means to have a
DoS (or downtime) signal.
Using two guards dumbly makes this rare. Both are down at the same time
by chance much less frequently than one is down, and a two-node DoS
search is harder to pull off when the adversary has to keep pairs (or
more) nodes offline at the same time, without taking other services
offline and causing false positives.
Using additional guards as soon as things fail makes these signals
absent, in theory. If a client is always trying to connect to new
guards, as long as the client can connect to the network, it will find a
guard that works pretty soon. This is also be another way of using two
guards dumbly, though.
> > 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.
> >
>
> Also it might be useful to rate the current guard design with these
> properties and see how well we are currently doing.
>
> IIUC, since we use all the primaries for dirguards it 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)
If by current design, you mean the current network as-is without
changing any consensus parameters, then these two aren't provided.
Since the current design is "num primary guard to use"=1, the current
design tries really hard to use only this guard. This means that as soon
as a hidden service chooses that guard as it's RP, it will use a second
guard. This second guard is normally unused. Hence: Hidden service use
pushed the service over to an unused guard.
Similarly, if website can cause a client to keep connecting through
different circuits over and over (via at least 3 different attacks,
mentioned in the other thread), then it can eventually cause that client
to use a second guard. We want to fix this for other reasons (guard
discovery), but that doesn't change it as a property here. And there may
be more like them if we fix just these three.
> Because of the path restrictions it also provides:
> 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.
Correct. It does provide these.
> It does *not* provide
> 2. Hidden service use can't influence your choice of 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).
Correct. It does not provide these.
> Let me know if I messed it up.
>
> Clearly since everyone in this thread wants to improve the current
> situation, the properties the current system lacks are important. In
> particular it seems like (2) and (6) are particularly important properties.
>
> >> 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.
> >
>
> How does it provide 7?
Woops, it does not. All it does is prevent the same *node* from being
used in the Guard and Exit position. I mixed that up with an earlier
revision of these properties...
> >> 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).
>
> How come Aaron's proposal provides the same benefits as Roger's even tho
> they different? Am I missing something?
Aaron's proposal actually does provide #7.
The key difference between the two is Roger's "Remove /16 and family
path restrictions between guard and last hop". That causes Roger to lose
#7. They also differ in the Guard+Exit flag assignment, but in this case
that does not change the properties provided, because no node
restrictions are removed.
> > <snip>
> >
> > 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.
>
> We already do this one. Primary guards come from the filtered set, and
> filtered set guards need to be listed in the consensus. See
> entry_guard_passes_filter(). If this is not the case in reality, it's a bug.
Good.
> >> * If both primary guards are down/not completing circuits, pick a new one.
> >
>
> Hmm, this is almost impossible to do. People with laptops and unstable
> networks frequently have both of their primary guards marked as
> unreachable while Tor is trying to reach network. Picking new primaries
> at that point would not be a good move.
Yuck. Well, minimizing this time/chance perhaps. Like if the client has
a TLS connection but both are failing all onionskins, then choose a
third?
> > 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.
>
> All in all I like the above proposal (modulo the issues above) and I
> think it's quite sane, and gets the best of most worlds ;) We should
> perhaps think more about it and try to spec it out! :)
I would prefer a proposal that has strong #6, but I think we are close
to that. All we need to do is prevent the case where "one guard down &&
guards can be chosen next to the RP."
Right now, I am leaning towards a hack that says "Vanguards can choose a
guard before the RP." We'd still be S - G - L2 - L3 - G - RP in that
case, though. As I said, an alternative is S - G - L2 - L3 - RP, but I
think I would rather preserve unlinkability for services run on the same
Tor client. A third alternative is trying to minimize the "only one
guard down" time. Such downtime minimization does seem tricky, though.
I would also like to try to beef up #4 as much as we can. If we can't
make all node downtime signals absent, we should aim to minimize them.
--
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