[or-cvs] first draft of the rendezvous section done
Roger Dingledine
arma at seul.org
Tue Oct 21 01:11:32 UTC 2003
Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc
Modified Files:
tor-design.tex tor-design.bib
Log Message:
first draft of the rendezvous section done
Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- tor-design.tex 20 Oct 2003 23:44:53 -0000 1.9
+++ tor-design.tex 21 Oct 2003 01:11:29 -0000 1.10
@@ -41,7 +41,7 @@
\title{Tor: Design of a Next-Generation Onion Router}
-\author{Anonymous}
+%\author{Anonymous}
%\author{Roger Dingledine \\ The Free Haven Project \\ arma at freehaven.net \and
%Nick Mathewson \\ The Free Haven Project \\ nickm at freehaven.net \and
%Paul Syverson \\ Naval Research Lab \\ syverson at itd.nrl.navy.mil}
@@ -120,7 +120,8 @@
communication behaviors, may be identifiable \cite{wright03}. To
complicate the possibility of such attacks Tor multiplexes many
connections down each circuit, but still rotates the circuit
-periodically to avoid too much linkability.
+periodically to avoid too much linkability from requests on a single
+circuit.
\item \textbf{No mixing or traffic shaping:} The original onion routing
design called for full link padding both between onion routers and between
@@ -128,10 +129,9 @@
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
-experience \cite{freedom} indicate that this level of resource
+experience \cite{freedom21-security} indicate 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}.
-% [XXX what is being referenced here, Dogan? -PS]
%[An upcoming FC04 paper. I'll add a cite when it's out. -RD]
\item \textbf{Leaky pipes:} Through in-band signalling within the
@@ -454,32 +454,28 @@
\SubSection{Directory Servers}
\label{subsec:dir-servers}
-\Section{Rendezvous points for location privacy}
+\Section{Rendezvous points: location privacy}
\label{sec:rendezvous}
Rendezvous points are a building block for \emph{location-hidden services}
-(that is, responder anonymity) in the Tor network. Location-hidden
+(aka responder anonymity) in the Tor network. Location-hidden
services means Bob can offer a tcp service, such as an Apache webserver,
without revealing the IP of that service.
-We provide censorship resistance for Bob by allowing him to advertise
-several onion routers (nodes known as his Introduction Points, see
-Section \ref{subsec:intro-point}) as his public location. Alice,
-the client, chooses a node known as a Meeting Point (see Section
-\ref{subsec: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 her meeting point. This extra level of indirection is needed
-so Bob's introduction points don't serve files directly (else they open
-themselves up to abuse, eg from serving Nazi propaganda in France). The
-extra level of indirection also allows Bob to choose which requests to
-respond to, and which to ignore.
+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
+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
+extra level of indirection also allows Bob to respond to some requests
+and ignore others.
-We provide the necessary glue code so that Alice can view
-webpages on a location-hidden webserver, and Bob can run a
-location-hidden server, with minimal invasive changes (see Section
-\ref{subsec:client-rendezvous}). Both Alice and Bob must run local
-onion proxies (OPs) -- software that knows how to talk to the onion
-routing network.
+We provide the necessary glue so that Alice can view webpages from Bob's
+location-hidden webserver with minimal invasive changes. Both Alice and
+Bob must run local onion proxies.
The steps of a rendezvous:
\begin{tightlist}
@@ -487,54 +483,86 @@
Distributed Hash Table (DHT).
\item Bob establishes onion routing connections to each of his
Introduction Points, and waits.
-\item Alice learns about Bob's service out of band (perhaps Bob gave her
- a pointer, or she found it on a website). She looks up the details
- of Bob's service from the DHT.
+\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
transaction.
\item Alice goes to one of Bob's Introduction Points, and gives it a blob
- (encrypted for Bob) which tells him about herself and the Meeting
- Point she chose. The Introduction Point sends the blob to Bob.
+ (encrypted for Bob) which tells him about herself, the Meeting Point
+ 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.
Let's assume the latter.
-\item MP plugs together Alice and Bob. Note that MP doesn't know (or care)
- who Alice is, or who Bob is; and it can't read anything they
- transmit either, because they share a session key.
-\item Alice sends a 'begin' cell along the circuit. It makes its way
- to Bob's onion proxy. Bob's onion proxy connects to Bob's webserver.
+\item MP plugs together Alice and Bob. Note that MP 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.
\item Data goes back and forth as usual.
\end{tightlist}
+When establishing an introduction point, Bob provides the onion router
+with a public ``introduction'' key. The hash of this public key
+identifies a unique service, and (since Bob is required to sign his
+messages) prevents anybody else from usurping Bob's introduction point
+in the future. Bob uses the same public key when establish the other
+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
+Alice, an optional authentication token so Bob 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
+other half of the DH key exchange.
+
+\subsection{Integration with user applications}
+
+For each service Bob offers, he configures his local onion proxy to know
+the local IP and port of the server, a strategy for authorizating Alices,
+and a public key. We assume the existence of a robust decentralized
+efficient lookup system which allows authenticated updates, eg
+\cite{cfs:sosp01}. (Each onion router could run a node in this lookup
+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
+that it's hidden behind the Tor network.
+
+As far as Alice's experience goes, we require that her client interface
+remain a SOCKS proxy, and we require that she shouldn't have to modify
+her applications. Thus we encode all of the necessary information into
+the hostname (more correctly, fully qualified domain name) that Alice
+uses, eg when clicking on a url in her browser. Location-hidden services
+use the special top level domain called `.onion': thus hostnames take the
+form x.y.onion where x encodes the hash of PK, and y is the authentication
+cookie. Alice's onion proxy examines hostnames and recognizes when they're
+destined for a hidden server. If so, it decodes the PK and starts the
+rendezvous as described in the table above.
+
+\subsection{Previous rendezvous work}
+
Ian Goldberg developed a similar notion of rendezvous points for
-low-latency anonymity systems \cite{goldberg-thesis}. His ``service tag''
+low-latency anonymity systems \cite{ian-thesis}. His ``service tag''
is the same concept as our ``hash of service's public key''. We make it
a hash of the public key so it can be self-authenticating, and so the
-client can recognize the same service with confidence later on.
-The main differences are:
-* We force the client to use our software. This means
- - the client can get anonymity for himself pretty easily, since he's
- already running our onion proxy.
- - the client can literally just click on a url in his Mozilla, paste it
- into wget, etc, and it will just work. (The url is a long-term
- service tag; like Ian's, it doesn't expire as the server changes
- public addresses. But in Ian's scheme it seems the client must
- manually hunt down a current location of the service via gnutella?)
- - the client and server can share ephemeral DH keys, so at no point
- in the path is the plaintext exposed.
-* I fear that we would get *no* volunteers to run Ian's rendezvous points,
- because they have to actually serve the Nazi propaganda (or whatever)
- in plaintext. So we add another layer of indirection to the system:
- the rendezvous service is divided into Introduction Points and
- Meeting Points. The introduction points (the ones that the server is
- publically associated with) do not output any bytes to the clients. And
- the meeting 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, the server doesn't even
- acknowledge its existence.
-
-
-\subsubsection{Integration with user applications}
+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
+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,
+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,
+the server doesn't even acknowledge its existence.
\Section{Maintaining anonymity sets}
\label{sec:maintaining-anonymity}
Index: tor-design.bib
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.bib,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- tor-design.bib 20 Oct 2003 23:44:53 -0000 1.2
+++ tor-design.bib 21 Oct 2003 01:11:29 -0000 1.3
@@ -568,14 +568,6 @@
note = {\url{http://www.firstmonday.dk/issues/issue2/remailers/}},
}
- at Misc{remailer-history-old,
- author = {Tim May},
- title = {Description of early remailer history},
- howpublished = {E-mail archived at
- \url{http://www.inet-one.com/cypherpunks/dir.1996.08.29-1996.09.04/
- msg00431.html}},
-}
-
@Article{chaum-mix,
author = {David Chaum},
title = {Untraceable electronic mail, return addresses, and digital pseudo-nyms},
@@ -598,12 +590,6 @@
note = {\newline \url{http://www.scs.cs.nyu.edu/~dm/}},
}
- at Misc{timmay,
- author = {Tim May},
- title = {Cyphernomicon},
- note = {\newline \url{http://www2.pro-ns.net/~crypto/cyphernomicon.html}},
-}
-
@misc{neochaum,
author = {Tim May},
title = {Payment mixes for anonymity},
@@ -611,30 +597,12 @@
\url{http://\newline www.inet-one.com/cypherpunks/dir.2000.02.28-2000.03.05/msg00334.html}},
}
- at misc{pidaho,
- author = {Joel McNamara},
- title = {{P}rivate {I}daho},
- note = {\newline \url{http://www.eskimo.com/~joelm/pi.html}},
-}
-
- at misc{potato,
- author = {RProcess},
- title = {{P}otato {S}oftware},
- note = {\newline \url{http://www.skuz.net/potatoware/}},
-}
-
@misc{helsingius,
author = {J. Helsingius},
title = {{\tt anon.penet.fi} press release},
note = {\newline \url{http://www.penet.fi/press-english.html}},
}
- at misc{mix-stats,
- author = {Christian Mock},
- title = {Mixmaster Stats ({A}ustria)},
- note = {\newline \url{http://www.tahina.priv.at/~cm/stats/mlist2.html}},
-}
-
@InProceedings{garay97secure,
author = {J. Garay and R. Gennaro and C. Jutla and T. Rabin},
title = {Secure distributed storage and retrieval},
@@ -691,50 +659,12 @@
year = {1997},
}
- at Misc{freedom,
- author = {Zero Knowledge Systems},
- title = {Freedom Version 2 White Papers},
- note = {\newline \url{http://www.freedom.net/info/whitepapers/}},
-}
-
-
- at Misc{recovery,
- author = {Miguel Castro and Barbara Liskov},
- title = {Proactive Recovery in a Byzantine-Fault-Tolerant System},
- note = {\newline \url{http://www.pmg.lcs.mit.edu/~castro/application/recovery.pdf}},
-}
-
@Misc{advogato,
author = {Raph Levien},
title = {Advogato's Trust Metric},
note = {\newline \url{http://www.advogato.org/trust-metric.html}},
}
- at Misc{rabin-ida,
- author = {Michael O. Rabin},
- title = {Efficient Dispersal of Information for security, load balancing,
- and fault tolerance},
- booktitle = {Journal of the ACM},
- year = {1989},
- volume = {36},
- number = {2},
- series = {335--348},
- month = {April},
-}
-
- at PhdThesis{malkin-thesis,
- author = {Tal Malkin},
- school = {{MIT}},
- title = {Private {I}nformation {R}etrieval},
- year = {2000},
- note = {\newline \url{http://toc.lcs.mit.edu/~tal/pubs.html}}
-}
-
- at Misc{zks,
- title = {Zero {K}nowledge {S}ystems},
- note = {\newline \url{http://www.freedom.net/}},
-}
-
@InProceedings{publius,
author = {Marc Waldman and Aviel Rubin and Lorrie Cranor},
title = {Publius: {A} robust, tamper-evident, censorship-resistant and
@@ -755,6 +685,24 @@
note = {\newline \url{http://www.freedom.net/products/whitepapers/white11.html}},
}
+ at techreport{freedom21-security,
+ title = {Freedom Systems 2.1 Security Issues and Analysis},
+ author = {Adam Back and Ian Goldberg and Adam Shostack},
+ institution = {Zero Knowledge Systems, {Inc.}},
+ year = {2001},
+ month = {May},
+ type = {White Paper},
+}
+
+ at inproceedings{cfs:sosp01,
+ title = {Wide-area cooperative storage with {CFS}},
+ author = {Frank Dabek and M. Frans Kaashoek and David Karger and Robert Morris and Ion Stoica},
+ booktitle = {Proceedings of the 18th {ACM} {S}ymposium on {O}perating {S}ystems {P}rinciples ({SOSP} '01)},
+ year = {2001},
+ month = {October},
+ address = {Chateau Lake Louise, Banff, Canada},
+}
+
@Article{raghavan87randomized,
author = {P. Raghavan and C. Thompson},
title = {Randomized rounding: A technique for provably good algorithms and algorithmic proofs},
@@ -878,6 +826,31 @@
pages = {58--70},
year = 2002,
publisher = {IEEE CS}
+}
+
+ at phdthesis{ian-thesis,
+ title = {A Pseudonymous Communications Infrastructure for the Internet},
+ author = {Ian Goldberg},
+ school = {UC Berkeley},
+ year = {2000},
+ month = {December},
+}
+
+ at inproceedings{wright02,
+ title = {An Analysis of the Degradation of Anonymous Protocols},
+ author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields},
+ booktitle = {Proceedings of the Network and Distributed Security Symposium - {NDSS} '02},
+ year = {2002},
+ month = {February},
+ publisher = {IEEE},
+}
+
+ at inproceedings{wright03,
+ title = {Defending Anonymous Communication Against Passive Logging Attacks},
+ author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields},
+ booktitle = {Proceedings of the 2003 IEEE Symposium on Security and Privacy},
+ year = {2003},
+ month = {May},
}
%%% Local Variables:
More information about the tor-commits
mailing list