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

[George Kadianakis]

Mike Perry <mikeperry at torproject.org> writes:

> Mike Perry:
>> teor:
>> > 
>> > 
>> > > On 25 Apr 2018, at 18:30, Mike Perry <mikeperry at torproject.org> wrote:
>> > > 
>> > > 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.
>> > 
>> > I think this list is missing some important user-visible properties, or it's
>> > not clear which property above corresponds to these properties:
>> > 
>> > * Is Tor reliable and responsive when guards go down, or when I move
>> >   networks, or when I have lost and regained service?
>> 
>> I think this is implicitly provided by #4. Downtime is a security issue.
>> If (any of) a client Guard(s) are down, and the adversary can detect
>> this based on client behavior, well, that is a side channel signal that
>> provides information about the Guard. So by satisfying #4, we also
>> satisfy the weaker conditions of general reliability and responsiveness.
>>  
>> > I also think it's missing an implicit property, which we should make explicit:
>> > 
>> > * Can Tor users be fingerprinted by their set of guards or directory guards?
>> > 
>> > Perhaps this property is out of scope.
>> 
>> I think it is worth considering. We should add it if we need to do
>> another round of evaluation.
>
> Alright, for the sake of argument, let's call this Property #8:
>   8. Less information from guard fingerprinting (the least information)
>
> I argue that this #8 is also equivalent to a #9 that Roger would ask
> for:
>   9. Fewer points of observation into the network (the fewest points).
>

If we are actually aiming for 8 and 9 we need to do something about the
numdirguard=3 situation, otherwise we still have a huge guard fpr and we
still expose ourselves to more of the network even if we keep one guard.

> To avoid TL;DR, that argument is an exercise to the reader ;).
>
> Here is a proposal that beats my previous proposal on Property #8 and
> #9, while trying to preserve as many of the other properties as
> possible:
>
>  * Set "num primary guards"=1 and "num primary guards to use"=1
>  * Set "num directory guards"=1 and "num directory guards to use"=1
>  * 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).
>  * Allow same /16 and same family for HS circuits.

This's for all hops? So all service-side HS circ hops can share the same
family? I gues that's OK since we don't know what's happening on the
other side of the HS circuit anyhow? Or what?

>  * When a primary guard leaves the consensus, pick a new one.
>  * When a primary guard fails circuits, do $MAGIC_FAILURE_HEURISTIC.

What is the $MAGIC_FAILURE_HEURISTIC supposed to do? Also I doubt we can
do anything magic here, we even have trouble doing very naive stuff when
it comes to network-uptime response.

>
> This proposal gets 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)
>   8. Less information from guard fingerprinting (the least information)
>
> It loses #4 (and your reliability point above), because if we transition
> to a second guard too quickly when the first one starts failing, then we
> lose the winning fingerprinting property we want to keep. So then
> therefore, we must tolerate failure and RESOURCELIMIT issues and suffer
> through connectivity issues during DoS:
>   4. DoS/Guard node downtime signals are rare (absent) 
>
> It then gets us 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.
>
> And again, we could get strong #6 if we allow the guard node for both RP
> and the node before the RP:
>   6. Information about the guard(s) does not leak to the website/RP (at all).
>
> So the key thing (in this property list) that forcing one guard causes us
> to lose is reliability under DoS, which is a guard discovery vector (and
> probably a source of other side channels, too).
>