Add proposal 170 "Configuration options regarding circuit building"

2 files changed, 97 insertions, 0 deletions

diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt
index 664c5654da..62327a1e61 100644
--- a/doc/spec/proposals/000-index.txt
+++ b/doc/spec/proposals/000-index.txt
@@ -90,6 +90,7 @@ Proposals by number:
 167  Vote on network parameters in consensus [CLOSED]
 168  Reduce default circuit window [OPEN]
 169  Eliminate TLS renegotiation for the Tor connection handshake [DRAFT]
+170  Configuration options regarding circuit building [DRAFT]
 
 
 Proposals by status:
@@ -101,6 +102,7 @@ Proposals by status:
    141  Download server descriptors on demand
    144  Increase the diversity of circuits by detecting nodes belonging the same provider
    169  Eliminate TLS renegotiation for the Tor connection handshake [for 0.2.2]
+   170  Configuration options regarding circuit building
  NEEDS-REVISION:
    131  Help users to verify they are using Tor
  OPEN:
diff --git a/doc/spec/proposals/170-user-path-config.txt b/doc/spec/proposals/170-user-path-config.txt
new file mode 100644
index 0000000000..fa74c76f73
--- /dev/null
+++ b/doc/spec/proposals/170-user-path-config.txt
@@ -0,0 +1,95 @@
+Title: Configuration options regarding circuit building
+Filename: 170-user-path-config.txt
+Author: Sebastian Hahn
+Created: 01-March-2010
+Status: Draft
+
+Overview:
+
+    This document outlines how Tor handles the user configuration
+    options to influence the circuit building process.
+
+Motivation:
+
+    Tor's treatment of the configuration *Nodes options was surprising
+    to many users, and quite a few conspiracy theories have crept up. We
+    should update our specification and code to better describe and
+    communicate what is going during circuit building, and how we're
+    honoring configuration. So far, we've been tracking a bugreport
+    about this behaviour (
+    https://bugs.torproject.org/flyspray/index.php?do=details&id=1090 )
+    and Nick replied in a thread on or-talk (
+    http://archives.seul.org/or/talk/Feb-2010/msg00117.html ).
+
+    This proposal tries to document our intention for those configuration
+    options.
+
+Design:
+
+    Five configuration options are available to users to influence Tor's
+    circuit building. EntryNodes and ExitNodes define a list of nodes
+    that are for the Entry/Exit position in all circuits. ExcludeNodes
+    is a list of nodes that are used for no circuit, and
+    ExcludeExitNodes is a list of nodes that aren't used as the last
+    hop. StrictNodes defines Tor's behaviour in case of a conflict, for
+    example when a node that is excluded is the only available
+    introduction point. Setting StrictNodes to 1 breaks Tor's
+    functionality in that case, and it will refuse to build such a
+    circuit.
+
+    Neither Nick's email nor bug 1090 have clear suggestions how we
+    should behave in each case, so I tried to come up with something
+    that made sense to me.
+
+Security implications:
+
+    Deviating from normal circuit building can break one's anonymity, so
+    the documentation of the above option should contain a warning to
+    make users aware of the pitfalls.
+
+Specification:
+
+    It is proposed that the "User configuration" part of path-spec
+    (section 2.2.2) be replaced with this:
+
+    Users can alter the default behavior for path selection with
+    configuration options. In case of conflicts (excluding and requiring
+    the same node) the "StrictNodes" option is used to determine
+    behaviour. If a nodes is both excluded and required via a
+    configuration option, the exclusion takes preference.
+
+    - If "ExitNodes" is provided, then every request requires an exit
+      node on the ExitNodes list. If a request is supported by no nodes
+      on that list, and "StrictNodes" is false, then Tor treats that
+      request as if ExitNodes were not provided.
+
+    - "EntryNodes" behaves analogously.
+
+    - If "ExcludeNodes" is provided, then no circuit uses any of the
+      nodes listed. If a circuit requires an excluded node to be used,
+      and "StrictNodes" is false, then Tor uses the node in that
+      position while not using any other of the excluded nodes.
+
+    - If "ExcludeExitNodes" is provided, then Tor will not use the nodes
+      listed for the exit position in a circuit. If a circuit requires
+      an excluded node to be used in the exit position and "StrictNodes"
+      is false, then Tor builds that circuit as if ExcludeExitNodes were
+      not provided.
+
+    - If a user tries to connect to or resolve a hostname of the form
+      <target>.<servername>.exit and the "AllowDotExit" configuration
+      option is set to 1, the request is rewritten to a request for
+      <target>, and the request is only supported by the exit whose
+      nickname or fingerprint is <servername>. If "AllowDotExit" is set
+      to 0 (default), any request for <anything>.exit is denied.
+
+    - When any of the *Nodes settings are changed, all circuits are
+      expired immediately, to prevent a situation where a previously
+      built circuit is used even though some of its nodes are now
+      excluded.
+
+
+Compatibility:
+
+    The old Strict*Nodes options are deprecated, and the StrictNodes
+    option is new. Tor users may need to update their configuration file.