[or-cvs] crank more on design section

Sun Oct 26 10:47:52 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:
crank more on design section


Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -d -r1.24 -r1.25

--- tor-design.tex	25 Oct 2003 11:41:26 -0000	1.24
+++ tor-design.tex	26 Oct 2003 10:47:49 -0000	1.25
@@ -50,15 +50,14 @@
 
 \begin{abstract}
 We present Tor, a connection-based low-latency anonymous communication
-system. It is intended as a successor to Onion Routing
-% how about removing 'intended as'? Simplifying further?
+system. Tor is the successor to Onion Routing
 and addresses many limitations in the original Onion Routing design.
 Tor works in a real-world Internet environment,
 % it's user-space too
 requires little synchronization or coordination between nodes, and
 protects against known anonymity-breaking attacks as well
 as or better than other systems with similar design parameters.
-% and we preseent a big list of open problems at the end
+% and we present a big list of open problems at the end
 \end{abstract}
 
 %\begin{center}
@@ -621,29 +620,118 @@
 router on the other side of the circuit connects to the destinations of
 the TCP streams and relays data.
 
+Onion routers have three types of keys. The first key is the identity
+(signing) key. An OR uses this key to sign TLS certificates, to sign its
+router descriptor (a summary of its keys, address, bandwidth, exit policy,
+etc), and to sign directories if it is a directory server. Changing the
+identity key of a router is considered equivalent to creating a new
+router. The second key is the onion (decryption) key, which is used
+for decrypting requests from users to set up a circuit and negotiate
+ephemeral keys. Thirdly, each OR shares link keys (generated by TLS)
+with the other ORs it's connected to. We discuss rotating these keys in
+Section \ref{subsec:rotating-keys}.
+
 Section \ref{subsec:cells} discusses the structure of the fixed-size
-\emph{cell} that are the unit of communication in Tor. We describe
-in Section \ref{subsec:circuits} how circuits work, and in Section
-\ref{subsec:circuit-build} how they are built, extended, truncated, and
-destroyed. Section \ref{subsec:tcp} discusses the process of opening
-TCP streams through Tor, and finally Section \ref{subsec:congestion}
-talks about congestion control and fairness issues.
+\emph{cells} that are the unit of communication in Tor. We describe
+in Section \ref{subsec:circuits} how circuits work, and how they are
+built, extended, truncated, and destroyed. Section \ref{subsec:tcp}
+discusses the process of opening TCP streams through Tor, and finally
+Section \ref{subsec:congestion} talks about congestion control and
+fairness issues.
 
 \SubSection{Cells}
+\label{subsec:cells}
 
-4.1 Describe cells.  Control versus Relay.  Cell structure.
+Traffic passes from node to node in fixed-size cells. Each cell is 256
+bytes, and consists of a header and a payload. The header includes the
+circuit identifier (ACI) which specifies which circuit the cell refers to
+(many circuits can be multiplexed over the single TCP connection between
+ORs or between an OP and an OR), and a command to describe what to do
+with the cell's payload. Cells are either control cells, meaning they are
+intended to be interpreted by the node that receives them, or relay cells,
+meaning they carry end-to-end stream data. Controls cells can be one of:
+\emph{padding} (currently used for keepalive, but can be used for link
+padding), \emph{create} or \emph{created} (to set up a new circuit),
+or \emph{destroy} (to tear down a circuit).
 
-4.2 Describe how circuits work and how relay cells get passed along,
+Relay cells have an additional header (the relay header) after the
+cell header, which specifies the stream identifier (many streams can
+be multiplexed over a circuit), an end-to-end checksum for integrity
+checking, and a relay command. Relay commands can be one of: \emph{relay
+data} (for data flowing down the stream), \emph{relay begin} (to open a
+stream), \emph{relay end} (to close a stream), \emph{relay connected}
+(to notify the OP that a relay begin has succeeded), \emph{relay
+extend} and \emph{relay extended} (to extend the circuit by a hop,
+and to acknowledge), \emph{relay truncate} and \emph{relay truncated}
+(to tear down only part of the circuit, and to acknowledge), \emph{relay
+sendme} (used for congestion control), and \emph{relay drop} (used to
+implement long-range dummies).
+
+We will talk more about each of these cell types below.
+
+% should there have been a table here? -RD
+
+\SubSection{Circuits and streams}
+\label{subsec:circuits}
+
+Users set up circuits incrementally, negotiating a symmetric key with
+each hop one at a time. To create a new circuit, the user (call her
+Alice) sends a \emph{create} cell to the first node in her chosen
+path. The payload is the first half of the Diffie-Hellman handshake,
+encrypted to the onion key of the OR (call him Bob). Bob responds with a
+\emph{created} cell with the second half of the DH handshake, along with
+a hash of $K=g^{xy}$. The goal is to get unilateral entity authentication
+(Alice knows she's handshaking with Bob, Bob doesn't care who it is ---
+recall that Alice has no key and is trying to remain anonymous) and
+unilateral key authentication (Alice and Bob agree on a key, and Alice
+knows Bob is the only other person who could know it). We also want
+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''}) \\
+\end{aligned}
+\end{equation}
+
+Being able to prove knowledge of this $K$ shows both that it was Bob
+who received $g^x$, and that it was Bob who came up with $y$. We use
+PK encryption in the first step (rather than, eg, using the first two
+steps of STS, which has a signature in the second step) because we
+don't have enough room in a single cell for a public key and also a
+signature. Preliminary analysis with the NRL protocol analyzer shows
+the above protocol to be secure (including providing PFS) under the
+traditional Dolev-Yao model.
+% cite Cathy? -RD
+% did I use the buzzwords correctly? -RD
+
+To extend a circuit past the first hop, Alice sends a \emph{relay extend}
+cell to the last node in the circuit, specifying the address of the new
+OR and an encrypted $g^x$ for it. That node copies the half-handshake
+into a \emph{create} cell, and passes it to the new OR to extend the
+circuit. When it responds with a \emph{created} cell, the penultimate OR
+copies the payload into a \emph{relay extended} cell and passes it back.
+% please fix my "that OR" pronouns -RD
+
+Once Alice shares a key with each OR on the circuit, she can
+start opening TCP streams over it. 
+
+Describe how circuits work and how relay cells get passed along,
 decrypted etc.  This will include mentioning leaky-pipe circuit
 topology and end-to-end integrity checking.  (Mention tagging.)
+Describe how circuits get built, extended, truncated.
 
-4.3 Describe how circuits get built, extended, truncated.
+\SubSection{Opening and closing streams}
+\label{subsec:tcp}
 
-4.4 Describe how TCP connections get opened.  (Mention DNS issues)
+Describe how TCP connections get opened.  (Mention DNS issues)
 Descibe closing TCP connections and 2-END handshake to mirror TCP
 close handshake.
 
-4.5 Describe circuit-level and stream-level
+\SubSection{Congestion control and fairness}
+\label{subsec:congestion}
+
+Describe circuit-level and stream-level
 congestion control issues and solutions.
 Describe circuit-level and stream-level fairness issues; cite Marc's
 anonnet stuff.
@@ -770,8 +858,7 @@
 only a few of them and they are more trusted. They listen on a separate
 port as an HTTP server, both so participants can fetch current network
 state and router lists (a \emph{directory}), and so other onion routers
-can upload a signed summary of their keys, address, bandwidth, exit
-policy, etc (\emph{server descriptors}.
+can upload their router descriptors.
 
 [[mention that descriptors are signed with long-term keys; ORs publish
     regularly to dirservers; policies for generating directories; key

