Add 241-suspicious-guard-turnover.txt

1 files changed, 174 insertions, 0 deletions

diff --git a/proposals/241-suspicious-guard-turnover.txt b/proposals/241-suspicious-guard-turnover.txt
new file mode 100644
index 0000000..a0313b2
--- /dev/null
+++ b/proposals/241-suspicious-guard-turnover.txt
@@ -0,0 +1,174 @@
+Filename: 241-suspicious-guard-turnover.txt
+Title: Resisting guard-turnover attacks
+Author: Aaron Johnson, Nick Mathewson
+Created: 2015-01-27
+Status: Draft
+
+1. Introduction
+
+  Tor uses entry guards to prevent an attacker who controls some
+  fraction of the network from observing a fraction of every user's
+  traffic. If users chose their entries and exits uniformly at
+  random from the list of servers every time they build a circuit,
+  then an adversary who had (k/N) of the network would deanonymize
+  F=(k/N)^2 of all circuits... and after a given user had built C
+  circuits, the attacker would see them at least once with
+  probability 1-(1-F)^C.  With large C, the attacker would get a
+  sample of every user's traffic with probability 1.
+
+  To prevent this from happening, Tor clients choose a small number
+  of guard nodes (currently 1: see proposal 236).  These guard nodes
+  are the only nodes that the client will connect to directly.  If
+  they are not compromised, the user's paths are not compromised.
+
+  But attacks remain.  Consider an attacker who can run a firewall
+  between a target user and the Tor network, and make
+  many of the guards they don't control appear to be unreachable.
+  Or consider an attacker who can identify a user's guards, and mount
+  denial-of-service attacks on them until the user picks a guard
+  that the attacker controls.
+
+  In the presence of these attacks, we can't continue to connect to
+  the Tor network unconditionally.  Doing so would eventually result
+  in the user chosing a hostile node as their guard, and losing
+  anonymity.
+
+
+
+
+2. Proposed behavior
+
+   Keep a record of all the guards we've tried to connect to,
+   connected to, or extended circuits through in the last PERIOD
+   days.
+
+   (We have connected to a guard if we authenticate its identity.
+   We have extended a circuit through a guard if we built a
+   multi-hop circuit with it.)
+
+   If the number of guards we have *tried* to connect to in the last
+   PERIOD days is greater than CANDIDATE_THRESHOLD, do not attempt
+   to connect to any other guards; only attempt the ones we have
+   previously *tried* to connect to.
+
+   If the number of guards we *have* connected to in the last PERIOD
+   days is greater than CONNECTED_THRESHOLD, do not attempt to
+   connect to any other guards; only attempt ones we have already
+   *successfully* connected to.
+
+   If we fail to connect to NET_THRESHOLD guards in a row, conclude
+   that the network is likely down. Stop/notify the user; retry
+   later; add no new guards for consideration.
+
+ [[ optional
+   If we notice that USE_THRESHOLD guards that we *used for
+   circuits* in the last FAST_REACT_PERIOD days are not working, but
+   some other guards are, assume that an attack is in progress, and
+   stop/notify the user.
+  ]]
+
+2.1. Suggested parameter thresholds.
+
+  PERIOD -- 60 days
+
+  FAST_REACT_PERIOD -- 10 days
+
+  CONNECTED_THRESHOLD -- 8
+
+  CANDIDATE_THRESHOLD -- 20
+
+  NET_THRESHOLD -- 10 (< CANDIDATE_THRESHOLD)
+
+ [[ optional
+  USE_THRESHOLD -- 3 (< CONNECTED_THRESHOLD)
+ ]]
+  (Each of the above should have a corresponding consensus parameter.)
+
+2.2. What do we mean by "Stop/warn"?
+
+  By default, we should probably give warnings in most of the above
+  cases for the first version that deploys them.  We can have an
+  on/off/auto setting for whether we will build circuits at all if we're
+  in a "stopped" mode.  Default should be auto, meaning off for now.
+
+  The warning needs to be carefully chosen, and suggest a workaround
+  better than "get a better network" or "clear your state file".
+
+2.3. What's with making USE_THRESHOLD optional?
+
+  Aaron thinks that getting rid of it might help in the fascistfirewall
+  case.  I'm a little unclear whether that makes any of the attacks
+  easier.
+
+3. State storage requirements
+
+Right now, we save for each guard that we have made contact with:
+
+   ID
+   Added
+   is dircache?
+   down-since
+   last-attempted
+   bad-since
+   chosen-on-date, chosen-by-version
+   path bias info (circ_attempts, successes, close_success)
+
+To implement the above proposal, we'll need to add, for each guard
+*or guard candidate*:
+   when did we first decide to try connecting to it?
+   when did we last do one of:
+       decide to try connecting to it?
+       connect to it?
+       build a multihop circuit through it?
+   which one was it?
+
+Probably round these to the nearest day or so.
+
+4. Future work
+
+   We need to make this play nicely with mobility.  When a user has
+   three guards on port 9001 and they move to a firewall that only
+   allows 80/443, we'd prefer that they not simply grind to a halt.  If
+   nodes are configured to stop when too many of their guards have gone
+   away, this will confuse them.
+
+   If people need to turn FascistFirewall on and off, great.  But if
+   they just clear their state file as a workaround, that's not so good.
+
+
+   If we could tie guard choice to location, that would help a great
+   deal, but we'd need to answer the question, "Where am I on the
+   network", which is not so easy to do passively if you're behind a
+   NAT.
+
+
+
+Appendix A. Scenario analysis
+
+A.1. Example attacks
+
+ * Filter Alice's connection so they can only talk to your guards.
+
+ * Whenever Alice is using a guard you don't control, DOS it.
+
+A.2. Example non-attacks
+
+ * Alice's guard goes down.
+
+ * Alice is on a laptop that is sometimes behind a firewall that
+   blocks a guard, and sometimes is not.
+
+ * Alice is on a laptop that's behind a firewall that blocks a lot
+   of the tor network, (like, everything not on 80/443).
+
+ * Alice has a network connection that sometimes turns off and turns
+   on again.
+
+ * Alice reboots her computer periodically, and tor starts a little
+   while before the network is live.
+
+Appendix B. Acknowledgements
+
+  Thanks to Rob Jansen and David Goulet for comments on earlier versions of
+  this draft.
+