[or-cvs] tweaks outside sec4 (couldn"t help myself)
Roger Dingledine
arma at seul.org
Sun Oct 26 23:49:04 UTC 2003
Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc
Modified Files:
tor-design.tex
Log Message:
tweaks outside sec4 (couldn't help myself)
Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -d -r1.28 -r1.29
--- tor-design.tex 26 Oct 2003 22:59:18 -0000 1.28
+++ tor-design.tex 26 Oct 2003 23:49:01 -0000 1.29
@@ -100,7 +100,7 @@
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 @@
\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 @@
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 @@
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 @@
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 @@
% 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 @@
\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 @@
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 @@
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 @@
\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 @@
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 @@
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 @@
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 @@
%
% '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
More information about the tor-commits
mailing list