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

Mike Perry mikeperry at torproject.org
Fri Apr 27 10:43:27 UTC 2018

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

But remmeber that we are already in the situation where Tor is using two
guards for a lot (or all) users right now: it uses a second guard right
now whenever an RP or Exit is the same as the Guard node, or is chosen
from the same /16 or family as the Guard node. Depending on how unlucky
you are, you could be using 2 guards pretty often right now. Just not
often enough to benefit from any multiplexing and netflow padding.

Tor also currently uses 3 directory guards, and unless we set "num entry
guards to use" and "num entry guards" to the same number, these are
different nodes than the primary guard. Miraculously, if we set this to
two, then Tor uses those two primary guards *as* its directory guards.
This means that any proposal that said "Set these to 2" has *less*
fingerprinting than those that did not. My proposal was the only one
that explicitly said this, but I think asn wants this too.

That means if we accept the proposal at the end of my mail, which gets
us strong #1-4, non-strong #5, strong #6 (with mods), and #7, then we'll
have less guard fingerprintability than today.

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/83af8b6e/attachment.sig>

More information about the tor-dev mailing list