From: Roger Dingledine Date: Tue, 21 Oct 2003 01:11:29 +0000 (+0000) Subject: first draft of the rendezvous section done X-Git-Tag: tor-0.0.2pre14~213 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=53baa69705ba0c3ac2da5b3b79821d57c3d5fbb5;p=thirdparty%2Ftor.git first draft of the rendezvous section done svn:r637 --- diff --git a/doc/tor-design.bib b/doc/tor-design.bib index 97a8d50d9f..8021195c4f 100644 --- a/doc/tor-design.bib +++ b/doc/tor-design.bib @@ -568,14 +568,6 @@ full_papers/rao/rao.pdf}}, note = {\url{http://www.firstmonday.dk/issues/issue2/remailers/}}, } -@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 @@ full_papers/rao/rao.pdf}}, note = {\newline \url{http://www.scs.cs.nyu.edu/~dm/}}, } -@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 @@ full_papers/rao/rao.pdf}}, \url{http://\newline www.inet-one.com/cypherpunks/dir.2000.02.28-2000.03.05/msg00334.html}}, } -@misc{pidaho, - author = {Joel McNamara}, - title = {{P}rivate {I}daho}, - note = {\newline \url{http://www.eskimo.com/~joelm/pi.html}}, -} - -@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}}, } -@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 @@ full_papers/rao/rao.pdf}}, year = {1997}, } -@Misc{freedom, - author = {Zero Knowledge Systems}, - title = {Freedom Version 2 White Papers}, - note = {\newline \url{http://www.freedom.net/info/whitepapers/}}, -} - - -@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}}, } -@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}, -} - -@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}} -} - -@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 @@ full_papers/rao/rao.pdf}}, note = {\newline \url{http://www.freedom.net/products/whitepapers/white11.html}}, } +@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}, +} + +@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}, @@ -880,6 +828,31 @@ full_papers/rao/rao.pdf}}, publisher = {IEEE CS} } +@phdthesis{ian-thesis, + title = {A Pseudonymous Communications Infrastructure for the Internet}, + author = {Ian Goldberg}, + school = {UC Berkeley}, + year = {2000}, + month = {December}, +} + +@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}, +} + +@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: %%% mode: latex %%% TeX-master: "tor-design" diff --git a/doc/tor-design.tex b/doc/tor-design.tex index 3ab0adaa1d..0ff4b72b4d 100644 --- a/doc/tor-design.tex +++ b/doc/tor-design.tex @@ -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@freehaven.net \and %Nick Mathewson \\ The Free Haven Project \\ nickm@freehaven.net \and %Paul Syverson \\ Naval Research Lab \\ syverson@itd.nrl.navy.mil} @@ -120,7 +120,8 @@ feasible. Those users, especially if they engage in certain unusual 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 @@ 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 -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 @@ tagging attacks \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 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 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 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 @@ The steps of a rendezvous: 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}