Mike Perry <mikepe...@torproject.org> writes:
> Mike Perry:
>> teor:
>> >
>> >
>> > > On 25 Apr 2018, at 18:30, Mike Perry <mikepe...@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).
>
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
