commit 8d01cca80734dbe3a380eccf5b647c8f5965d682 Author: Nick Mathewson nickm@torproject.org 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.