[tor-dev] Proposal #291 Properties (was IRC meeting)

[George Kadianakis]

Mike Perry <mikeperry at 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
>> 
>> 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.

>   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?

>   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)

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.

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).

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?

>
> <snip>
>
>> 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?

> <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.

>>  * 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.

> 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! :)

Let's see what other people think.