[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Update prop 237 at author's request
commit 8d01cca80734dbe3a380eccf5b647c8f5965d682
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date: Thu Jul 9 15:21:17 2015 -0400
Update prop 237 at author's request
---
proposals/237-directory-servers-for-all.txt | 123 +++++++++++++--------------
1 file 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.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits