From c277b742f446c3d2c8c7a00812a0b09d1b996455 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Sat, 21 Apr 2007 17:48:50 +0000 Subject: [PATCH] r12489@catbus: nickm | 2007-04-21 13:48:39 -0400 The ten thousandth Tor commit: add two new proposals (one from Mike Perry about randomized path length, and one from me about simplifyin authority operation) and expand and/or refine serveral older ones. Most notable there are changes to 103 that will allow us to make authorities more resistant to key compromise. svn:r10000 --- doc/spec/proposals/000-index.txt | 2 + doc/spec/proposals/101-dir-voting.txt | 9 +- doc/spec/proposals/103-multilevel-keys.txt | 99 ++++++++- doc/spec/proposals/104-short-descriptors.txt | 7 + .../112-bring-back-pathlencoinweight.txt | 209 ++++++++++++++++++ .../113-fast-authority-interface.txt | 80 +++++++ 6 files changed, 399 insertions(+), 7 deletions(-) create mode 100644 doc/spec/proposals/112-bring-back-pathlencoinweight.txt create mode 100644 doc/spec/proposals/113-fast-authority-interface.txt diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index fe60a7b083..ca0586a986 100644 --- a/doc/spec/proposals/000-index.txt +++ b/doc/spec/proposals/000-index.txt @@ -30,3 +30,5 @@ Proposals by number: 109 No more than one server per IP address [ACCEPTED] 110 Avoiding infinite length circuits [OPEN] 111 Prioritizing local traffic over relayed traffic [OPEN] +112 Bring Back Patlen Coin Weight [OPEN] +113 Simplifying directory authority administration [OPEN] \ No newline at end of file diff --git a/doc/spec/proposals/101-dir-voting.txt b/doc/spec/proposals/101-dir-voting.txt index a4ca459c4d..aba0adf653 100644 --- a/doc/spec/proposals/101-dir-voting.txt +++ b/doc/spec/proposals/101-dir-voting.txt @@ -90,9 +90,14 @@ Proposal: 2. Details. +2.0. Versioning + + All documents generated here have version "3" given in their + network-status-version entries. + 2.1. Vote specifications - Votes in v2.1 are similar to v2 network status documents. We add these + Votes in v3 are similar to v2 network status documents. We add these fields to the preamble: "vote-status" -- the word "vote". @@ -122,7 +127,7 @@ Proposal: 2.2. Consensus directory specifications - Consensuses are like v2.1 votes, except for the following fields: + Consensuses are like v3 votes, except for the following fields: "vote-status" -- the word "consensus". diff --git a/doc/spec/proposals/103-multilevel-keys.txt b/doc/spec/proposals/103-multilevel-keys.txt index 0e0c83bf08..474d3f2250 100644 --- a/doc/spec/proposals/103-multilevel-keys.txt +++ b/doc/spec/proposals/103-multilevel-keys.txt @@ -57,10 +57,99 @@ Proposal: (who will expect descriptors to be signed by the identity keys they know and love, and who will not understand signing keys) happy. - I'd enumerate designs here, but I'm hoping that somebody will come up with - a better one, so I'll try not to prejudice them with more ideas yet. +A possible solution: - Oh, and of course, we'll want to make sure that the keys are - cross-certified. :) + One thing to consider is that router identity keys are not very sensitive: + if an OR disappears and reappears with a new key, the network treats it as + though an old router had disappeared and a new one had joined the network. + The Tor network continues unharmed; this isn't a disaster. - Ideas? -NM + Thus, the ideas above are mostly relevant for authorities. + + The most straightforward solution for the authorities is probably to take + advantage of the protocol transition that will come with proposal 101, and + introduce a new set of signing _and_ identity keys used only to sign votes + and consensus network-status documents. Signing and identity keys could be + delivered to users in a separate, rarely changing "keys" document, so that + the consensus network-status documents wouldn't need to include N signing + keys, N identity keys, and N certifications. + + Note also that there is no reason that the identity/signing keys used by + directory authorities would necessarily have to be the same as the identity + keys those authorities use in their capacity as routers. Decoupling these + keys would give directory authorities the following set of keys: + + Directory authority identity: + Highly confidential; stored encrypted and/or offline. Used to + identity directory authorities. Shipped with clients. Used to + sign Directory authority signing keys. + + Directory authority signing key: + Stored online, accessible to regular Tor process. Used to sign + votes and consensus directories. Downloaded as part of a "keys" + document. + + [Administrators SHOULD rotate their signing keys every month or + two, just to keep in practice and keep from forgetting the + password to the authority identity.] + + V1-V2 directory authority identity: + Stored online, never changed. Used to sign legacy network-status + and directory documents. + + Router identity: + Stored online, seldom changed. Used to sign server descriptors + for this authority in its role as a router. Implicitly certified + by being listed in network-status documents. + + Onion key, link key: + As in tor-spec.txt + + +Extensions to Proposal 101. + + Add the following elements to vote documents: + + "dir-identity-key": The long-term identity key for this authority. + "dir-key-published": The time when this directory's signing key was last + changed. + "dir-key-certification": A signature of the fields "fingerprint", + "dir-key-published", "dir-signing-key", and "dir-identity-key", + concatenated, in that order. The signed material extends from the + beginning of "fingerprint" through the newline after + "dir-key-certification". The identity key is used to generate this + signature. + + The elements "fingerprint", "dir-key-published", "dir-signing-key", + "dir-identity-key", and "dir-key-certification" together constitute a + "key certificate". These are generated offline when starting a v2.1 + authority. + + The elements "dir-signing-key", "dir-key-published", and + "dir-identity-key", "dir-key-certification" and MUST NOT appear in + consensus documents. + + The "fingerprint" field is generated based on the identity key, not + the signing key. + + Consensus network statues change as follows: + + Remove dir-signing-key. + + Change "directory-signature" to take a fingerprint of the authority's + identity key rather than the authority's nickname. + + Add a new document type: + + A "keys" document contains all currently known key certification + certificates. All authorities serve it at + + http:///tor/status/keys.z + + Caches and clients download the keys document whenever they receive a + consensus vote that uses a key they do not recognize. Caches download + from authorities; clients download from caches. + + Verification: + + [XXXX write me] \ No newline at end of file diff --git a/doc/spec/proposals/104-short-descriptors.txt b/doc/spec/proposals/104-short-descriptors.txt index 44e4ae7af9..9392acb672 100644 --- a/doc/spec/proposals/104-short-descriptors.txt +++ b/doc/spec/proposals/104-short-descriptors.txt @@ -122,6 +122,13 @@ Specification: the digest of the extra-info document. * The published fields in the two documents match. + Authorities SHOULD drop extra-info documents that do not meet these + criteria. + + Extra-info documents MAY be uploaded as part of the same HTTP post as + the router descriptor, or separately. Authorities MUST accept both + methods. + Authorities SHOULD try to fetch extra-info documents from one another if they do not have one matching the digest declared in a router descriptor. diff --git a/doc/spec/proposals/112-bring-back-pathlencoinweight.txt b/doc/spec/proposals/112-bring-back-pathlencoinweight.txt new file mode 100644 index 0000000000..a08b5c6678 --- /dev/null +++ b/doc/spec/proposals/112-bring-back-pathlencoinweight.txt @@ -0,0 +1,209 @@ +Filename: 112-bring-back-pathlencoinweight.txt +Title: Bring Back Pathlen Coin Weight +Version: +Last-Modified: +Author: Mike Perry +Created: +Status: Open + + +Overview: + + The idea is that users should be able to choose a weight which + probabilistically chooses their path lengths to be 2 or 3 hops. This + weight will essentially be a biased coin that indicates an + additional hop (beyond 2) with probability P. The user should be + allowed to choose 0 for this weight to always get 2 hops and 1 to + always get 3. + + This value should be modifiable from the controller, and should be + available from Vidalia. + + +Motivation: + + The Tor network is slow and overloaded. Increasingly often I hear + stories about friends and friends of friends who are behind firewalls, + annoying censorware, or under surveillance that interferes with their + productivity and Internet usage, or chills their speech. These people + know about Tor, but they choose to put up with the censorship because + Tor is too slow to be usable for them. In fact, to download a fresh, + complete copy of levine-timing.pdf for the Anonymity Implications + section of this proposal over Tor took me 3 tries. + + There are many ways to improve the speed problem, and of course we + should and will implement as many as we can. Johannes's GSoC project + and my reputation system are longer term, higher-effort things that + will still provide benefit independent of this proposal. + + However, reducing the path length to 2 for those who do not need the + (questionable) extra anonymity 3 hops provide not only improves + their Tor experience but also reduces their load on the Tor network by + 33%, and can be done in less than 10 lines of code. That's not just + Win-Win, it's Win-Win-Win. + + Furthermore, when blocking resistance measures insert an extra relay + hop into the equation, 4 hops will certainly be completely unusable + for these users, especially since it will be considerably more + difficult to balance the load across a dark relay net than balancing + the load on Tor itself (which today is still not without its flaws). + + +Anonymity Implications: + + It has long been established that timing attacks against mixed + networks are extremely effective, and that regardless of path + length, if the adversary has compromised your first and last + hop of your path, you can assume they have compromised your + identity for that connection. + + In [1], it is demonstrated that for all but the slowest, lossiest + networks, error rates for false positives and false negatives were + very near zero. Only for constant streams of traffic over slow and + (more importantly) extremely lossy network links did the error rate + hit 20%. For loss rates typical to the Internet, even the error rate + for slow nodes with constant traffic streams was 13%. + + When you take into account that most Tor streams are not constant, + but probably much more like their "HomeIP" dataset, which consists + mostly of web traffic that exists over finite intervals at specific + times, error rates drop to fractions of 1%, even for the "worst" + network nodes. + + Therefore, the user has little benefit from the extra hop, assuming + the adversary does timing correlation on their nodes. The real + protection is the probability of getting both the first and last hop, + and this is constant whether the client chooses 2 hops, 3 hops, or 42. + + Partitioning attacks form another concern. Since Tor uses telescoping + to build circuits, it is possible to tell a user is constructing only + two hop paths at the entry node. It is questionable if this data is + actually worth anything though, especially if the majority of users + have easy access to this option, and do actually choose their path + lengths semi-randomly. + + Nick has postulated that exits may also be able to tell that you are + using only 2 hops by the amount of time between sending their + RELAY_CONNECTED cell and the first bit of RELAY_DATA traffic they + see from the OP. I doubt that they will be able to make much use + of this timing pattern, since it will likely vary widely depending + upon the type of node selected for that first hop, and the user's + connection rate to that first hop. It is also questionable if this + data is worth anything, especially if many users are using this + option (and I imagine many will). + + Perhaps most seriously, two hop paths do allow malicious guards + to easily fail circuits if they do not extend to their colluding peers + for the exit hop. Since guards can detect the number of hops in a + path, they could always fail the 3 hop circuits and focus on + selectively failing the two hop ones until a peer was chosen. + + I believe currently guards are rotated if circuits fail, which does + provide some protection, but this could be changed so that an entry + guard is completely abandoned after a certain number of extend or + general circuit failures, though perhaps this also could be gamed + to increase guard turnover. Such a game would be much more noticeable + than an individual guard failing circuits, though, since it would + affect all clients, not just those who chose a particular guard. + + +Why not fix Pathlen=2?: + + The main reason I am not advocating that we always use 2 hops is that + in some situations, timing correlation evidence by itself may not be + considered as solid and convincing as an actual, uninterrupted, fully + traced path. Are these timing attacks as effective on a real network + as they are in simulation? Would an extralegal adversary or authoritarian + government even care? In the face of these situation-dependent unknowns, + it should be up to the user to decide if this is a concern for them or not. + + +Implementation: + + new_route_len() can be modified directly with a check of the + PathlenCoinWeight option (converted to percent) and a call to + crypto_rand_int(0,100) for the weighted coin. + + The Vidalia setting should probably be in the network status window + as a slider, complete with tooltip, help documentation, and perhaps + an "Are you Sure?" checkbox. + + The entry_guard_t structure could have a num_circ_failed member + such that if it exceeds N circuit extend failure to a second hop, + it is removed from the entry list. N should be sufficiently high + to avoid churn from normal Tor circuit failure, and could possibly be + represented as a ratio of failed to successful circuits through that + guard. + + +Migration: + + Phase one: Re-enable config and modify new_route_len() to add an + extra hop if coin comes up "heads". + + Phase two: Experiment with the proper ratio of circuit failures + used to expire garbage or malicious guards. + + Phase three: Make slider or entry box in Vidalia, along with help entry + that explains in layman's terms the risks involved. + + +[1] http://www.cs.umass.edu/~mwright/papers/levine-timing.pdf + + +============================================================ + +I love replying to myself. I can't resist doing it. Sorry. "Think twice +post once" is a concept totally lost on me, especially when I'm wrong +the first two times ;) + + +Thus spake Mike Perry (mikepery@fscked.org): + +> Why not fix Pathlen=2?: +> +> The main reason I am not advocating that we always use 2 hops is that +> in some situations, timing correlation evidence by itself may not be +> considered as solid and convincing as an actual, uninterrupted, fully +> traced path. Are these timing attacks as effective on a real network +> as they are in simulation? Would an extralegal adversary or authoritarian +> government even care? In the face of these situation-dependent unknowns, +> it should be up to the user to decide if this is a concern for them or not. + +Hrmm.. it should probably also be noted that even a false positive +rate of 1% for a 200k concurrent-user network could mean that for a +given node, a given stream could be confused with something like 10 +users, assuming ~200 nodes carry most of the traffic (ie 1000 users +each). Though of course to really know for sure, someone needs to do +an attack on a real network, unfortunately. + +For this reason this option should instead be represented not as a +slider, but as a straight boolean value, at least in Vidalia. + +Perhaps something like a radiobutton: + + * "I use Tor for Censorship Resistance, not Anonymity. Speed is more + important to me than Anonymity." + * "I use Tor for Anonymity. I need extra protection at the cost of speed." + +and then some explanation in the help for exactly what this means, and +the risks involved with eliminating the adversary's need for timing attacks +wrt to false positives, etc. + +This radio button can then also be used to toggle Johannes's work, +should it be discovered that using latency/bandwidth measurements +gives the adversary some information as to your location or likely +node choices. Or we can create a series of choices along these lines +as more load balancing/path choice optimizations are developed. + +---- + +So what does this change mean wrt to the proposal process? Should I +submit a new proposal? I'm still on the fence if the underlying torrc +option and Tor implementation should be a coin weight or a fixed +value, so at this point really all this changes is the proposed +Vidalia behavior (Vidalia is an imporant part of this proposal, +because it would be nice to take 33% of the load off the network for +all users who do not need 3 hops). + + diff --git a/doc/spec/proposals/113-fast-authority-interface.txt b/doc/spec/proposals/113-fast-authority-interface.txt new file mode 100644 index 0000000000..49829086e7 --- /dev/null +++ b/doc/spec/proposals/113-fast-authority-interface.txt @@ -0,0 +1,80 @@ +Filename: 113-fast-authority-interface.txt +Title: Simplifying directory authority administration +Version: $Revision: 12412 $ +Last-Modified: $Date: 2007-04-16T19:11:29.511998Z $ +Author: Nick Mathewson +Created: +Status: Open + +Overview + +The problem: + + Administering a directory authority is a pain: you need to go through + emails and manually add new nodes as "named". When bad things come up, + you need to mark nodes (or whole regions) as invalid, badexit, etc. + + This means that mostly, authority admins don't: only 2/4 current authority + admins actually bind names or list bad exits, and those two have often + complained about how annoying it is to do so. + + Worse, name binding is a common path, but it's a pain in the neck: nobody + has done it for a couple of months. + +Digression: who knows what? + + It's trivial for Tor to automatically keep track of all of the + following information about a server: + name, fingerprint, IP, last-seen time, first-seen time, declared + contact. + + All we need to have the administrator set is: + - Is this name/fingerprint pair bound? + - Is this fingerprint/IP a bad exit? + - Is this fingerprint/IP an invalid node? + - Is this fingerprint/IP to be rejected? + + The workflow for authority admins has two parts: + - Periodically, go through tor-ops and add new names. This doesn't + need to be done urgently. + - Less often, mark badly behaved serves as badly behaved. This is more + urgent. + +Possible solution #1: Web-interface for name binding. + + Deprecate use of the tor-ops mailing list; instead, have operators go to a + webform and enter their server info. This would put the information in a + standardized format, thus allowing quick, nearly-automated approval and + reply. + +Possible solution #2: Self-binding names. + + Peter Palfrader has proposed that names be assigned automatically to nodes + that have been up and running and valid for a while. + +Possible solution #3: Self-maintaining approved-routers file + + Mixminion alpha has a neat feature where whenever a new server is seen, + a stub line gets added to a configuration file. For Tor, it could look + something like this: + + ## First seen with this key on 2007-04-21 13:13:14 + ## Stayed up for at least 12 hours on IP 192.168.10.10 + #RouterName AAAABBBBCCCCDDDDEFEF + + (Note that the implementation needs to parse commented lines to make sure + that it doesn't add duplicates, but that's not so hard.) + + To add a router as named, administrators would only need to uncomment the + entry. This automatically maintained file could be kept separately from a + manually maintained one. + + This could be combined with solution #2, such that Tor would do the hard + work of uncommenting entries for routers that should get Named, but + operators could override its decisions. + +Possible solution #4: A separate mailing list for authority operators. + + Right now, the tor-ops list is very high volume. There should be another + list that's only for dealing with problems that need prompt action, like + marking a router as !badexit.