George Kadianakis:
Mike Perry mikeperry@torproject.org 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
- 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:
- Hidden service use can't push you over to an unused guard (at all).
- 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).
- Exits and websites can't push you over to an unused guard (at all)
- 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.
- Nodes are not reused for Guard and Exit positions ("any" positions)
- Information about the guard(s) does not leak to the website/RP (at all).
- 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:
- Hidden service use can't push you over to an unused guard (at all).
- 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:
- Hidden service use can't push you over to an unused guard (at all).
- 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:
- Hidden service use can't push you over to an unused guard (at all).
- Hidden service use can't influence your choice of guard (at all).
- Exits and websites can't push you over to an unused guard (at all)
- 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.