commit 6e4752c66689b7e5512cb5355d679718fbb23a38 Author: Nick Mathewson nickm@torproject.org Date: Tue Oct 27 13:38:21 2015 -0400

[257] Refactoring authorities and taking parts offline --- proposals/000-index.txt | 2 + proposals/257-hiding-authorities.txt | 206 ++++++++++++++++++++++++++++++++++ 2 files changed, 208 insertions(+)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt index d9a161d..c5fabc9 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -177,6 +177,7 @@ Proposals by number: 254 Padding Negotiation [DRAFT] 255 Controller features to allow for load-balancing hidden services [DRAFT] 256 Key revocation for relays and authorities [OPEN] +257 Refactoring authorities and taking parts offline [DRAFT]

Proposals by status: @@ -200,6 +201,7 @@ Proposals by status: 253 Out of Band Circuit HMACs 254 Padding Negotiation 255 Controller features to allow for load-balancing hidden services + 257 Refactoring authorities and taking parts offline NEEDS-REVISION: 190 Bridge Client Authorization Based on a Shared Secret OPEN: diff --git a/proposals/257-hiding-authorities.txt b/proposals/257-hiding-authorities.txt new file mode 100644 index 0000000..330bb03 --- /dev/null +++ b/proposals/257-hiding-authorities.txt @@ -0,0 +1,206 @@ +Filename: 257-hiding-authorities.txt +Title: Refactoring authorities and taking parts offline +Authors: Nick Mathewson, Andrea Shepard +Created: 2015-10-27 +Status: Draft + +1. Introduction + + Directory authorities are critical to the Tor network, and represent + a DoS target to anybody trying to disable the network. This document + describes a strategy for making directory authorities in general less + vulnerable to DoS by separating the different parts of their + functionality. + +2. Design + +2.1. The status quo + + This proposal is about splitting up the roles of directory + authorities. But, what are these roles? Currently, directory + authorities perform the following functions. + + Some of these functions require large amounts of bandwidth; I've noted + that with a (BW). Some of these functions require a publicly known + address; I've marked those with a (PUB). Some of these functions + inevitably leak the location from which they are performed. I've marked + those with a (LOC). + + Not everything in this list is something that needs to be done by an + authority permanently! This list is, again, just what authorities do now. + + * Authorities receive uploaded server descriptors and extrainfo + descriptors from regular Tor servers and from each other. (BW, PUB?) + + * Authorities periodically probe the routers they know about in + order to determine whether they are running or not. By + remembering the past behavior of nodes, they also build a view of + each node's fractional uptime and mean time between + failures. (LOC, unless we're clever) + + * Authorities perform the consensus protocol by: + + * Generating 'vote' documents describing their view of the + network, along with a set of microdescriptors for later + client use. + + * Uploading these votes to one another. + + * Computing a 'consensus' of these votes. + + * Authorities serve as a location for distributing consensus + documents, descriptors, extrainfo documents, and + microdescriptors... + + * To directory mirrors. (BW?, PUB?, LOC?) + + * To clients that do not yet know a directory mirror. (BW!!, PUB) + + These functions are tied to directory authorities, but done + out-of-process: + + * Bandwidth measurement (BW) + + * Sybil detection + + * 'Guardiness' measurement, possibly. + +2.2. Design goals + + Principally, we attempt to isolate the security-critical, + high-resource, and availability-critical pieces of our directory + infrastructure from one another. + + We would like to make the security-critical pieces of our + infrastructure easy to relocate, and the communications between them + easy to secure. + + We require that the Tor network remain able to bootstrap itself in + the event of catastrophic failure. So, while we can _use_ a running + Tor network to communicate, we should not _require_ that a running + Tor network exist in order to perform the voting process. + +2.3. Division of responsibility + + We propose dividing directory authority operations into these modules: + + + ---------- ---------- -------------- ---------------- + | Upload |======>| Voting |===>| Publishing |===>| Distribution | + ---------- ---------- -------------- ---------------- + I ^ + I ----------- I + ====>| Metrics |=== + ----------- + + A number of 'upload' servers are responsible for receiving + router descriptors. These are publicly known, and responsible for + collecting descriptors. + + Information from these servers is used by 'metrics' modules + (which check Tor servers for reliability and measure their history), + and fed into the voting process. + + The voting process involves only communication (indirectly) from + authorities to authorities, to produce a consensus and a set of + microdescriptors. + + When voting is complete, consensuses, descriptors, and microdescriptors + must be made available to the rest of the world. This is done by + the 'publishing' module. The consensuses, descriptors, and mds are then + taken up by the directory caches, and distributed. + + The rest of this proposal will describe means of communication between + these modules. + +3. The modules in more detail + + This section will outline possibilities for communication between the + various parts of the system to isolate them. There will be plenty of + "may"s and "could"s and "might"s here: these are possibilities, in + need of further consideration. + +3.1. Sending descriptors to the Upload module + + We retain the current mechanism: a set of well-known IP + addresses with well-known OR keys to which each relay should upload a + copy of its descriptors. + + The worst that a hostile upload server can do is to drop descriptors. + (It could also generate large numbers of spurious descriptors in + order to increase the load on the metrics system. But an attacker + could do that without running an upload server) + + With respect to dropping, upload servers can use an anytrust model: + so long as a single server receives and honestly reports descriptors + to the rest of the system, those descriptors will arrive correctly. + + To avoid DoS attacks, we can require that any relay not previously known + to an upload module perform some kind of a proof of work as it first + registers itself. (Details TBD) + + If we're using TLS here, we should also consider a check-then-start TLS + design as described in A.1 below. + + The location of Upload servers can change over time; they can be + published in the consensus. + + (Note also that as an alternative, we could distribute this functionality + across the whole network.) + +3.2. Transferring descriptors to the metrics server and the voters + + The simplest option here would be for the authorities and metrics + servers to mirror them using Tor. rsync-over-ssh-over-Tor is a + possibility, if we don't feel like building more machinery. + + (We could use hidden services here, but it is probably okay for + upload servers and to be known by the the voters and metrics.) + + A fallback to a non-Tor connection could be done manually, or could + require explicit buy-in from the voter/metrics operator. + +3.3. Transferring information from metrics server to voters + + The same approaches as 3.2 should work fine. + +3.4. Communication between voters + + Voters can, we hope, communicate to each other over authenticated + hidden services. But we'll need a fallback mechanism here. + + Another option is to have public ledgers available for voters to talk + to anonymously. This is probably a better idea. We could re-use the + upload servers for this purpose, perhaps. + + Giving voters each others' addresses seems like a bad idea. + +3.5. Communication from voters to directory nodes + + We should design a flood-distribution mechanism for microdescriptors, + listed descriptors, and consensuses so that authorities can each + upload to a few targets anonymously, and have them propagate through + the rest of the network. + +4. Migration + + To support old clients and old servers, the current authority IP + addresses should remain as Upload and Distribution points. The + current authority identity keys keys should remain as the keys for + voters. + +A.1. Check-then-start TLS + + Current TLS protocols are quite susceptible to denial-of-service + attacks, with large asymmetries in resource consumption. (Client + sends junk, forcing server to perform private-key operation on junk.) + + We could hope for a good TLS replacement to someday emerge, or for + TLS to improve its properties. But as a replacement, I suggest that + we wrap TLS in a preliminary challenge-response protocol to establish + that the use is authorized before we allow the TLS handshake to + begin. + + (We shouldn't do this for all the TLS in Tor: only for the cases + where we want to restrict the users of a given TLS server.) +