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

[Mike Perry]

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

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.
 * When a primary guard leaves the consensus, pick a new one.
 * When a primary guard fails circuits, do $MAGIC_FAILURE_HEURISTIC.

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


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180427/6a736b1b/attachment.sig>