Update prop 237 at author's request

1 files changed, 60 insertions, 63 deletions

diff --git a/proposals/237-directory-servers-for-all.txt b/proposals/237-directory-servers-for-all.txt
index bc5aad2..0ce9296 100644
--- a/proposals/237-directory-servers-for-all.txt
+++ b/proposals/237-directory-servers-for-all.txt
@@ -3,44 +3,37 @@ Title: All relays are directory servers
 Author: Matthew Finkel
 Created: 29-Jul-2014
 Status: Open
-Target: 0.2.6.x
+Target: 0.2.7.x
 
 Overview:
 
-      This proposal aims at removing part of the distinction between the
-  relay and the directory server. Currently operators have the options
-  of being one of: a relay, a directory server, or both.  With the
-  acceptance of this proposal the options will be simplified to being
-  either only a directory server or a combined relay and directory
-  server. All relays will serve directory requests.
+      This proposal aims at simplying how users interact directly with
+  the Tor network by turning all relays into directory servers (also
+  known as directory caches), too.  Currently an operator has the
+  options of running a relay, a directory server, or both.  With the
+  acceptance (and implementation) of this proposal the options will be
+  simplified by having (nearly) all relays cache and serve directory
+  documents, without additional configuration.
 
 Motivation:
 
-      Fetching directory documents and descriptors is sometimes a
-  non-trivial operation for clients. If they do not have a consensus then
-  they must contact a directory authority (until directory sources are
-  added or clients are able to use a fallback consensus). If they have a
-  consensus and have at least one entry guard then the client can query
-  that guard for documents. If the document isn't available then after a
-  period of time the client will attempt to retry downloading it. If the
-  entry guard isn't a directory server, as well, a directory server and/or
-  directory guard must be chosen (based on the server having an open
-  DirPort) and queried for the document. At a minimum, this has a
-  potential performance impact, at worst it's another attack vector that
-  allows for profiling clients and partitioning users. With the
+      Fetching directory documents and descriptors is not always a
+  simple operation for a client. This is especially true and potentially
+  dangerous when the client would prefer querying its guard but its
+  guard is not a directory server. When this is the case, the client
+  must choose and query a distinct directory server. At best this should
+  not be necessary and at worst, it seems, this adds another position
+  within the network for profiling and partitioning users. With the
   orthogonally proposed move to clients using a single guard, the
-  potential performance bottleneck and ability to profile users could be
-  exacerbated. If the client selects an entry guard and it is not a
-  directory server then the client may select a distinct directory guard
-  which will leak client behavior to a second node. In the case where the
-  client does not use guards, it is important to have the largest possible
-  amount of diversity in the set of directory servers. In a network where
+  resulting benefits could be reduced by clients using distinct
+  directory servers. In addition, in the case where the client does not
+  use guards, it is important to have the largest possible amount of
+  diversity in the set of directory servers. In a network where (almost)
   every relay is a directory server, the profiling and partitioning
-  attack vector is reduced to the guard (for clients who use them), which
-  is already in a privileged position for this. In addition, with the
-  increased set size relay descriptors and documents are more readily
-  available and it diversifies the providers.
-
+  attack vector is reduced to the guard (for clients who use them),
+  which is already in a privileged position for this. In addition, with
+  the increased set size, relay descriptors and documents are more
+  readily available and it diversifies the providers.
 
 Design:
 
@@ -59,14 +52,15 @@ Design:
       The presence of this line indicates that the relay accepts
   tunnelled directory requests. For a relay that implements this
   proposal, this line MUST be added to its descriptor if it does not
-  advertise a directory port, and MAY be added if it also advertises an
-  open directory port. In addition to this, relays will now download and
-  cache all descriptors and documents listed in the consensus, regardless
-  of whether they are deemed useful or usable, exactly like the current
-  directory servers. All relays will also accept directory requests when
-  they are tunnelled over a connection established with a BEGIN_DIR cell,
-  the same way these connections are already accepted by bridges and
-  directory servers with an open DirPort.
+  advertise a directory port, and the line MAY be added if it also
+  advertises an open directory port. In addition to this, relays will
+  now download and cache all descriptors and documents listed in the
+  consensus, regardless of whether they are deemed useful or usable,
+  exactly like the current directory server behavior. All relays will
+  also accept directory requests when they are tunnelled over a
+  connection established with a BEGIN_DIR cell, the same way these
+  connections are already accepted by bridges and directory servers with
+  an open DirPort.
 
       Directory Authorities will now assign the V2Dir flag to a server if
   it supports a version of the directory protocol which is useful to
@@ -76,28 +70,23 @@ Design:
 
       Clients choose a directory by using the current criteria with the
   additional criterion that a server only needs the V2Dir status flag
-  instead of requiring an open DirPort. When the client chooses which
-  directory server it will query, it checks if the server has an open
-  directory port and uses begindir if it does not have one. Directory
-  servers should not be able to determine which version of Tor the client
-  is using (or a lower-bound on the version), if possible. Continuing to
-  prefer direct directory connections over begin may help mitigate a
-  potential partitioning attack.
+  instead of requiring an open DirPort.
 
 Security Considerations and Implications:
 
       Currently all directory servers are explicitly configured. This is
   necessary because they must have a configured and reachable external
-  port.  However, this is a restriction and results in a reduced number of
-  directory servers on the network. As a result, this could allow an
-  adversary to control a significant fraction of the servers. By
-  increasing the number of directory servers on the network the likelihood
-  of selecting one that is malicious is reduced. Also, with this proposal,
-  it will be more likely that a client's entry guard is also a directory
-  server (as alluded to in Proposal 207). However, the reduced anonymity
-  set caused when the guard does not have, or is unwilling to distribute,
-  a specific document still exists. With the increased diversity in the
-  available servers, the impact of this should be reduced.
+  port. However, within Tor, this requires additional configuration and
+  results in a reduced number of directory servers in the network. As a
+  consequence, this could allow an adversary to control a non-negligable
+  fraction of the servers. By increasing the number of directory servers
+  in the network the likelihood of selecting one that is malicious is
+  reduced. Also, with this proposal, it will be more likely that a
+  client's entry guard is also a directory server (as alluded to in
+  Proposal 207). However, the reduced anonymity set created when the
+  guard does not have, or is unwilling to distribute, a specific
+  document still exists. With the increased diversity in the available
+  servers, the impact of this should be reduced.
 
       Another question that may need further consideration is whether we
   trust bad directories to be good guards and exits.
@@ -113,19 +102,27 @@ Specification:
 Impact on local resources:
 
       Should relays attempt to download documents from another mirror
-  before asking an authority? All relays will now prefer contacting the
-  authorities first, but this will not scale well and will partition users
-  from relays.
+  before asking an authority? All relays, with minor exceptions, will
+  now contact the authorities for documents, but this will not scale
+  well and will partition users from relays.
 
       If all relays become directory servers, they will choose to
   download all documents, regardless of whether they are useful, in case
-  another client does want them. This will have very little impact on the
-  "typical" relay, however on memory constrained relays (BeagleBone,
+  another client does want them. This will have very little impact on
+  the most relays, however on memory constrained relays (BeagleBone,
   Raspberry Pi, and similar), every megabyte allocated to directory
-  documents is not available for new circuits. Should we add a config
-  option that allows operators to disable being a directory server?  Is
-  it more worthwhile for them to serve these documents or to relay cells?
+  documents is not available for new circuits. For this reason, a new
+  configuration option will be introduced within Tor for these systems,
+  named DirCache, which the operator may choose to set as 0, thus
+  disabling caching of directory documents and denying client directory
+  requests.
 
 Future Considerations:
 
       Should the DirPort be deprecated at some point in the future?
+
+      Write a proposal requiring that a relay must have the V2Dir flag
+  as a criterion for being a guard.
+
+      Is V2Dir a good name for this? It's the name we currently use, but
+  that's a silly reason to continue using it.