[tor-dev] [RFC] On new guard algorithms and data structures

[l.m]

> Thanks for the input!

Hey, no problem. Thank you for working on this too.

> Can you suggest a retry amount and time interval?

If the adversary is at the gateway and can do filtering, they pretty
much want some rotation. Whatever that reason may be (choose a guard
you've already chosen, or choose some other which may be adversarial).
In the case you describe, I would minimize retry and maximize interval
size. Sorry for being unspecific. The reason being if your client has
selected and not connected, the adversary may become aware of this
selection. They can then fingerprint your use when you change
locations using the guards. It acts as a foothold to launch further
attacks. It means even if the adversary doesn't initially succeed
against you, then can always resume their efforts later.

A simplification might be to have the client explicitly state location
changes. More than just detecting ip changes like tor. When you start
TBB you make a choice, or in the torrc. Easier than network awareness
for tor. You're at a trusted location or unknown. If the location is
trusted then less skepticism is needed when forced to choose a new
guard, or if you should retry connecting, and how often.

If the location is otherwise you expect some degree of third-party
interference is likely. You expect that rotation is unlikely to be
benign (you may already have a compromised guard). The guard which was
just chosen should be treated with skepticism, network interruption
and outage is likely suspicious, and any friendly guards can be used
to identify you if you change location where this gateway is still
used. Here you find the airport example. Are long-lived guards and the
default path selection implementation as secure here. Some analysis is
in order. Maybe short-lived (and not persistent) guards, and tuned
path selection, is as good as long-lived guards at the trusted
location? The whole question of whether the entry guards concept can
work effectively in an untrusted location is being questioned here.

It might be better to just default-drop guards between untrusted
location, while persisting guards at explicitly trusted locations.

Some symptoms of this adversary are: unable to bootstrap from
dirauths, guards which were working have now become unlisted/down,
client behaviors symptomatic of censorship which persist between
locations unless guards dropped, traffic flows begin to favor a
particular guard over time after multiple rotations, multiple guards
become unreachable at the same time when another guard is chosen.
--leeroy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150820/d00e0606/attachment-0001.html>