[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r10000: The ten thousandth Tor commit: add two new proposals (one fr (in tor/trunk: . doc/spec/proposals)
- To: or-cvs@xxxxxxxxxxxxx
- Subject: [or-cvs] r10000: The ten thousandth Tor commit: add two new proposals (one fr (in tor/trunk: . doc/spec/proposals)
- From: nickm@xxxxxxxx
- Date: Sat, 21 Apr 2007 13:48:58 -0400 (EDT)
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivery-date: Sat, 21 Apr 2007 13:49:08 -0400
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-cvs@xxxxxxxxxxxxx
Date: 2007-04-21 13:48:50 -0400 (Sat, 21 Apr 2007)
New Revision: 10000
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.
Property changes on: tor/trunk
svk:merge ticket from /tor/trunk [r12489] on 8246c3cf-6607-4228-993b-4d95d33730f1
--- tor/trunk/doc/spec/proposals/000-index.txt 2007-04-21 17:48:45 UTC (rev 9999)
+++ tor/trunk/doc/spec/proposals/000-index.txt 2007-04-21 17:48:50 UTC (rev 10000)
@@ -30,3 +30,5 @@
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
--- tor/trunk/doc/spec/proposals/101-dir-voting.txt 2007-04-21 17:48:45 UTC (rev 9999)
+++ tor/trunk/doc/spec/proposals/101-dir-voting.txt 2007-04-21 17:48:50 UTC (rev 10000)
@@ -90,9 +90,14 @@
+ 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 @@
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".
--- tor/trunk/doc/spec/proposals/103-multilevel-keys.txt 2007-04-21 17:48:45 UTC (rev 9999)
+++ tor/trunk/doc/spec/proposals/103-multilevel-keys.txt 2007-04-21 17:48:50 UTC (rev 10000)
@@ -57,10 +57,99 @@
(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"
+ [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
+ "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
+ 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
+ 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
+ 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.
+ [XXXX write me]
\ No newline at end of file
--- tor/trunk/doc/spec/proposals/104-short-descriptors.txt 2007-04-21 17:48:45 UTC (rev 9999)
+++ tor/trunk/doc/spec/proposals/104-short-descriptors.txt 2007-04-21 17:48:50 UTC (rev 10000)
@@ -122,6 +122,13 @@
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
+ Extra-info documents MAY be uploaded as part of the same HTTP post as
+ the router descriptor, or separately. Authorities MUST accept both
Authorities SHOULD try to fetch extra-info documents from one another if
they do not have one matching the digest declared in a router
--- tor/trunk/doc/spec/proposals/112-bring-back-pathlencoinweight.txt 2007-04-21 17:48:45 UTC (rev 9999)
+++ tor/trunk/doc/spec/proposals/112-bring-back-pathlencoinweight.txt 2007-04-21 17:48:50 UTC (rev 10000)
@@ -0,0 +1,209 @@
+Title: Bring Back Pathlen Coin Weight
+Author: Mike Perry
+ 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.
+ 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).
+ 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 , 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.
+ 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
+ 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.
+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@xxxxxxxxxx):
+> 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).
--- tor/trunk/doc/spec/proposals/113-fast-authority-interface.txt 2007-04-21 17:48:45 UTC (rev 9999)
+++ tor/trunk/doc/spec/proposals/113-fast-authority-interface.txt 2007-04-21 17:48:50 UTC (rev 10000)
@@ -0,0 +1,80 @@
+Title: Simplifying directory authority administration
+Version: $Revision: 12412 $
+Last-Modified: $Date: 2007-04-16T19:11:29.511998Z $
+Author: Nick Mathewson
+ 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
+ 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
+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
+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.