[or-cvs] put in some notes about rendezvous points

[Roger Dingledine]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc

Modified Files:
	tor-design.tex 
Log Message:
put in some notes about rendezvous points
i'll tie these together more in a bit

and answer/introduce a few questions in section 1


Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- tor-design.tex	16 Oct 2003 21:49:04 -0000	1.6
+++ tor-design.tex	17 Oct 2003 11:04:39 -0000	1.7
@@ -22,6 +22,14 @@
 %   \pdftrue
 %\fi
 
+\newenvironment{tightlist}{\begin{list}{$\bullet$}{
+  \setlength{\itemsep}{0mm}
+    \setlength{\parsep}{0mm}
+    %  \setlength{\labelsep}{0mm}
+    %  \setlength{\labelwidth}{0mm}
+    %  \setlength{\topsep}{0mm}
+    }}{\end{list}}
+
 \begin{document}
 
 %% Use dvipdfm instead. --DH
@@ -77,7 +85,7 @@
 federated onion routers that provides the following improvements over
 the old onion routing design:
 
-\begin{itemize}
+\begin{tightlist}
 
 \item \textbf{Perfect forward secrecy:} The original onion routing
 design is vulnerable to a single hostile node recording traffic and later
@@ -100,11 +108,16 @@
 onion routing design built one circuit for each request. Aside from the
 performance issues of doing public key operations for every request, it
 also turns out that regular communications patterns mean building lots
-of circuits, which can endanger anonymity \cite{wright03}. [XXX Was this
-supposed to be Wright02 or Wright03. In any case I am hesitant to cite
-that work in this context. While the point is valid in general, that
-work is predicated on assumptions that I don't think typically apply
-to onion routing (whether old or new design).]
+of circuits, which can endanger anonymity \cite{wright03}.
+%[XXX Was this
+%supposed to be Wright02 or Wright03. In any case I am hesitant to cite
+%that work in this context. While the point is valid in general, that
+%work is predicated on assumptions that I don't think typically apply
+%to onion routing (whether old or new design). -PS]
+%[I had meant wright03, but I guess wright02 could work as well.
+% If you don't think these attacks work on onion routing, you need to
+% write up a convincing argument of this. Such an argument would
+% be very worthwhile to include in this paper. -RD]
 Tor multiplexes many
 connections down each circuit, but still rotates the circuit periodically
 to avoid too much linkability.
@@ -117,8 +130,9 @@
 into detail. However, recent research \cite{econymics} and deployment
 experience \cite{freedom} 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?]
+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 circuit,
 Tor initiators can direct traffic to nodes partway down the circuit. This
@@ -126,7 +140,7 @@
 \cite{defensive-dropping}, but because circuits are used by more than
 one application, it also allows traffic to exit the circuit from the
 middle -- thus frustrating timing attacks based on observing exit points.
-%Or something like that. hm.
+%Or something like that. hm. Tone this down maybe? Or support it. -RD
 
 \item \textbf{Congestion control:} Earlier anonymity designs do not
 address traffic bottlenecks. Unfortunately, typical approaches to load
@@ -160,7 +174,7 @@
 \item \textbf{Rendezvous points:}
 location-protected servers
 
-\end{itemize}
+\end{tightlist}
 
 We review previous work in Section \ref{sec:background}, describe
 our goals and assumptions in Section \ref{sec:assumptions},
@@ -366,8 +380,87 @@
 \SubSection{Directory Servers}
 \label{subsec:dir-servers}
 
-\Section{Rendezvous points: pseudonyms with responder anonymity}
+\Section{Rendezvous points for 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
+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.
+
+The steps of a rendezvous:
+\begin{tightlist}
+\item Bob chooses some Introduction Points, and advertises them on a
+      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 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.
+\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 Data goes back and forth as usual.
+\end{tightlist}
+
+Ian Goldberg developed a similar notion of rendezvous points for
+low-latency anonymity systems \cite{goldberg-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}
 
 \Section{Maintaining anonymity sets}
 \label{sec:maintaining-anonymity}