From 2d603ea957b3f8532bd1e9aea5eb29957512adf8 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Sun, 26 Oct 2003 23:49:01 +0000 Subject: [PATCH] tweaks outside sec4 (couldn't help myself) svn:r680 --- doc/tor-design.tex | 87 ++++++++++++++++++++++++---------------------- 1 file changed, 45 insertions(+), 42 deletions(-) diff --git a/doc/tor-design.tex b/doc/tor-design.tex index e104cc485e..71131fa7fc 100644 --- a/doc/tor-design.tex +++ b/doc/tor-design.tex @@ -100,7 +100,7 @@ Rather than using a single onion to lay each circuit, Tor now uses an incremental or \emph{telescoping} path-building design, where the initiator negotiates session keys with each successive hop in the circuit. Once these keys are deleted, -subsequent compromised nodes cannot decrypt old traffic. +subsequently compromised nodes cannot decrypt old traffic. As a side benefit, onion replay detection is no longer necessary, and the process of building circuits is more reliable, since the initiator knows when a hop fails and can then try extending to a new node. @@ -122,7 +122,7 @@ incorporate those features itself. \item \textbf{Many TCP streams can share one circuit:} The original Onion Routing design built a separate circuit for each application-level request. -This hurt perfomance by requiring multiple public key operations for +This hurt performance by requiring multiple public key operations for every request, and also presented a threat to anonymity (see Section~\ref{maintaining-anonymity}). \footnote{The first Onion Routing design \cite{or-ih96} protected against @@ -145,20 +145,18 @@ onion routers. The current Tor design multiplexes multiple TCP streams along each virtual circuit, in order to improve efficiency and anonymity. -\item \textbf{No mixing, padding, or traffic shaping:} -The original Onion Routing -design called for full link padding both between onion routers and between -onion proxies (that is, users) and onion routers \cite{or-jsac98}. The +\item \textbf{No mixing, padding, or traffic shaping:} The original +Onion Routing design called for mixing of data from each circuit, +plus full link padding both between onion routers and between onion +proxies (that is, users) and onion routers \cite{or-jsac98}. The later analysis paper \cite{or-pet00} suggested \emph{traffic shaping} to provide similar protection but use less bandwidth, but did not go -into detail. However, recent research \cite{econymics} and deployment +into detail. However, recent research \cite{econymics} and deployment experience \cite{freedom21-security} suggest that this level of resource use is not practical or economical; and even full link padding is still -vulnerable to active attacks \cite{defensive-dropping}. -%[An upcoming FC04 paper. I'll add a cite when it's out. -RD] -Thus, absent a proven design for traffic shaping, Tor currently generates -no dummy traffic. -% We don't mention mixing in the above, but we mention it in the title. -NM +vulnerable \cite{defensive-dropping}. Thus, until we have a proven and +convenient design for traffic shaping or low-latency mixing that will help +anonymity against a realistic adversary, we leave these strategies out. \item \textbf{Leaky-pipe circuit topology:} Through in-band signalling within the @@ -180,11 +178,10 @@ congestion control maintains reasonable anonymity while allowing nodes at the edges of the network to detect congestion or flooding attacks and send less data until the congestion subsides. -\item \textbf{Directory servers:} Rather take the original Onion -Routing's approach and attempting to flood -link-state information through the network --- an approach which can be -unreliable and -open to partitioning attacks or outright deception --- Tor takes a simplified +\item \textbf{Directory servers:} The original Onion Routing design +planned to flood link-state information through the network --- an +approach which can be unreliable and +open to partitioning attacks or outright deception. Tor takes a simplified view towards distributing link-state information. Certain more trusted onion routers also serve as directory servers; they provide signed \emph{directories} describing all routers they know about, and which @@ -229,19 +226,23 @@ each operator is comfortable with allowing different types of traffic to exit the Tor network from his node. \item \textbf{Implementable in user-space:} Because it only attempts to -anonymize TCP streams, Tor differs from some other anonymity -systems\cite{freedom} in that it does not require patches to an operating +anonymize TCP streams, Tor differs from other anonymity systems like +Freedom \cite{freedom} in that it does not require patches to an operating system's network stack in order to operate. Although this approach is less -flexible, it has proven valuable to Tor's portability and deployabilitiy. +flexible, it has proven valuable to Tor's portability and deployability. \item \textbf{Rendezvous points and location-protected servers:} Tor -provides an integrated mechanism for responder-anonymity +provides an integrated mechanism for responder anonymity via location-protected servers. Previous Onion Routing designs included long-lived ``reply onions'' which could be used to build virtual -circuits towards a hidden server, but this design is vulnerable to -flooding attacks, and is incompatible with forward security. In Tor's +circuits to a hidden server, but this approach is +brittle because a reply onion becomes useless if any node in the +path goes down or rotates its keys, and it's also +%vulnerable to flooding attacks, +% no it isn't. no more than our rendezvous point approach at least -RD +incompatible with forward security. In Tor's current design, clients use {\it introduction points} to negotiate {\it - rendezvous points} to connect with hidden servers, and reply onions +rendezvous points} to connect with hidden servers; and reply onions are no longer required. \end{tightlist} @@ -528,7 +529,7 @@ The basic adversary components we consider are: % for later. -PS -\item{Hostile Tor node:] can arbitrarily manipulate the +\item{Hostile Tor node:} can arbitrarily manipulate the connections under its control, as well as creating new connections (that pass through itself). \end{description} @@ -735,7 +736,7 @@ perfect forward secrecy, key freshness, etc. \begin{equation} \begin{aligned} \mathrm{Alice} \rightarrow \mathrm{Bob}&: E_{PK_{Bob}}(g^x) \\ -\mathrm{Bob} \rightarrow \mathrm{Alice}&: g^y, H(K | \mathrm{``handshake''}) \\ +\mathrm{Bob} \rightarrow \mathrm{Alice}&: g^y, H(K | \mathrm{``handshake"}) \\ \end{aligned} \end{equation} @@ -893,7 +894,7 @@ without just making the whole network wide open. even limiting most nodes to allow http, ssh, and aim to exit and reject all other stuff is sketchy, because plenty of abuse can happen over -port 80. but it's a good start, because it blocks most things, +port 80. but it's a surprisingly good start, because it blocks most things, and because people are more used to the concept of port 80 abuse not coming from the machine's owner. @@ -1028,7 +1029,8 @@ We provide this censorship resistance for Bob by allowing him to advertise several onion routers (his \emph{Introduction Points}) as his public location. Alice, the client, chooses a node for her \emph{Meeting Point}. She connects to one of Bob's introduction points, informs him -about her meeting point, and then waits for him to connect to the meeting +about her rendezvous point, and then waits for him to connect to the +rendezvous point. This extra level of indirection means Bob's introduction points don't open themselves up to abuse by serving files directly, eg if Bob chooses a node in France to serve material distateful to the French. The @@ -1048,15 +1050,15 @@ The steps of a rendezvous: \item Alice learns about Bob's service out of band (perhaps Bob told her, or she found it on a website). She looks up the details of Bob's service from the DHT. -\item Alice chooses and establishes a Meeting Point (MP) for this +\item Alice chooses and establishes a Rendezvous Point (RP) for this transaction. \item Alice goes to one of Bob's Introduction Points, and gives it a blob - (encrypted for Bob) which tells him about herself, the Meeting Point + (encrypted for Bob) which tells him about herself, the RP she chose, and the first half of an ephemeral key handshake. The Introduction Point sends the blob to Bob. -\item Bob chooses whether to ignore the blob, or to onion route to MP. +\item Bob chooses whether to ignore the blob, or to onion route to RP. Let's assume the latter. -\item MP plugs together Alice and Bob. Note that MP can't recognize Alice, +\item RP plugs together Alice and Bob. Note that RP can't recognize Alice, Bob, or the data they transmit (they share a session key). \item Alice sends a Begin cell along the circuit. It arrives at Bob's onion proxy. Bob's onion proxy connects to Bob's webserver. @@ -1073,11 +1075,11 @@ introduction points for that service. The blob that Alice gives the introduction point includes a hash of Bob's public key to identify the service, an optional initial authentication token (the introduction point can do prescreening, eg to block replays), -and (encrypted to Bob's public key) the location of the meeting point, -a meeting cookie Bob should tell the meeting point so he gets connected to +and (encrypted to Bob's public key) the location of the rendezvous point, +a rendezvous cookie Bob should tell RP so he gets connected to Alice, an optional authentication token so Bob can choose whether to respond, -and the first half of a DH key exchange. When Bob connects to the meeting -place and gets connected to Alice's pipe, his first cell contains the +and the first half of a DH key exchange. When Bob connects to RP +and gets connected to Alice's pipe, his first cell contains the other half of the DH key exchange. % briefly talk about our notion of giving cookies to people proportional @@ -1095,7 +1097,7 @@ system; also note that as a stopgap measure, we can just run a simple lookup system on the directory servers.) Bob publishes into the DHT (indexed by the hash of the public key) the public key, an expiration time (``not valid after''), and the current introduction points for that -service. Note that Bob's webserver is completely oblivious to the fact +service. Note that Bob's webserver is unmodified, and doesn't even know that it's hidden behind the Tor network. As far as Alice's experience goes, we require that her client interface @@ -1119,12 +1121,13 @@ client can recognize the same service with confidence later on. His design differs from ours in the following ways though. Firstly, Ian suggests that the client should manually hunt down a current location of the service via Gnutella; whereas our use of the DHT makes lookup faster, -more robust, and transparent to the user. Secondly, the client and server -can share ephemeral DH keys, so at no point in the path is the plaintext +more robust, and transparent to the user. Secondly, in Tor the client +and server can share ephemeral DH keys, so at no point in the path is +the plaintext exposed. Thirdly, our design is much more practical for deployment in a volunteer network, in terms of getting volunteers to offer introduction -and meeting point services. The introduction points do not output any -bytes to the clients. And the meeting points don't know the client, +and rendezvous point services. The introduction points do not output any +bytes to the clients, and the rendezvous points don't know the client, the server, or the stuff being transmitted. The indirection scheme is also designed with authentication/authorization in mind -- if the client doesn't include the right cookie with its request for service, @@ -1343,4 +1346,4 @@ deploying a wider network. We will see what happens! % % 'Substitute ``Damn'' every time you're inclined to write ``very;'' your % editor will delete it and the writing will be just as it should be.' -% -- Mark Twain \ No newline at end of file +% -- Mark Twain