From 93f3eec00c3f3a1ddf6dfaf789cc32675ff66087 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Mon, 3 Nov 2003 12:07:02 +0000 Subject: patches on nick's sec4 patches svn:r734 --- doc/tor-design.tex | 44 ++++++++++++++++++++++++-------------------- 1 file changed, 24 insertions(+), 20 deletions(-) (limited to 'doc') diff --git a/doc/tor-design.tex b/doc/tor-design.tex index a84230f53..6baac8323 100644 --- a/doc/tor-design.tex +++ b/doc/tor-design.tex @@ -531,8 +531,8 @@ the identity key of a router is considered equivalent to creating a new router. The onion (decryption) key is used for decrypting requests from users to set up a circuit and negotiate ephemeral keys. Finally, link keys are used by the TLS protocol when communicating between -onion routers. Both short-term keys are rotated periodically and -independantly, to limit the impact of compromised keys. +onion routers. Each short-term key is rotated periodically and +independently, to limit the impact of key compromise. Section~\ref{subsec:cells} discusses the structure of the fixed-size \emph{cells} that are the unit of communication in Tor. We describe @@ -545,7 +545,7 @@ fairness issues. \SubSection{Cells} \label{subsec:cells} -ORs communicate with one another, and with users' OPs, via TLS +Onion routers communicate with one another, and with users' OPs, via TLS connections with ephemeral keys. This prevents an attacker from impersonating an OR, conceals the contents of the connection with perfect forward secrecy, and prevents an attacker from modifying data @@ -556,16 +556,16 @@ is 256 bytes (but see Section~\ref{sec:conclusion} for a discussion of allowing large cells and small cells on the same network), and consists of a header and a payload. The header includes a circuit identifier (circID) that specifies which circuit the cell refers to -(many circuits are be multiplexed over the single TLS connection), and +(many circuits can be multiplexed over the single TLS connection), and a command to describe what to do with the cell's payload. (Circuit -identifiers are connection-specific; a single circuit has a different -circID on each connection it uses.) +identifiers are connection-specific: each single circuit has one circID +for the forward connection and another for the backward connection.) % XXX Say that each OR can have many circuits with same circID, so % XXX long as they're on different connections, and that ORs know % XXX which circIDs/connection pairs are linked by a circuit. Based on their command, cells are either \emph{control} cells, which are always interpreted by the node that receives them, or \emph{relay} cells, -which carry end-to-end stream data. The controls cells commands are: +which carry end-to-end stream data. The control cell commands are: \emph{padding} (currently used for keepalive, but also usable for link padding); \emph{create} or \emph{created} (used to set up a new circuit); and \emph{destroy} (to tear down a circuit). @@ -643,20 +643,20 @@ into a \emph{relay extended} cell and passes it back to Alice. Now the circuit is extended to Carol, and Alice and Carol share a common key $K_2 = g^{x_2 y_2}$. -In order to extend the circuit to a third node or beyond, Alice +To extend the circuit to a third node or beyond, Alice proceeds as above, always telling the last node in the circuit to extend one hop further. -% XXX Briefly mention path selection. +% XXX Briefly mention path selection and path length. This circuit-level handshake protocol achieves unilateral entity -authentication (Alice knows she's handshaking with Bob/Carol, but -Bob/Carol doesn't care who is opening the circuit---Alice has no key +authentication (Alice knows she's handshaking with the OR, but +the OR doesn't care who is opening the circuit---Alice has no key and is trying to remain anonymous) and unilateral key authentication -(Alice and Bob/Carol agree on a key, and Alice knows Bob/Carol is the -only other person who should know it). It also achieves forward -secrecy and key freshness. Formally, the protocol is as follows -(Where $E_{PK_{Bob}}(\cdot)$ is encryption with Bob's public key, -$H$ is a secure hash function, and $|$ is concatenation.) +(Alice and the OR agree on a key, and Alice knows the OR is the +only other entity who should know it). It also achieves forward +secrecy and key freshness. More formally, the protocol is as follows +(where $E_{PK_{Bob}}(\cdot)$ is encryption with Bob's public key, +$H$ is a secure hash function, and $|$ is concatenation): \begin{equation} \begin{aligned} @@ -682,7 +682,7 @@ OR on the circuit), she can send relay cells. % XXX encrypted. The easiest expository order should probably be: What ORs % XXX Do With Unrecognized Streams; What Alice Does To Build Relay % XXX Cells; What ORs Do With Streams They Recognize. -Recall that every relay header has a stream ID in the relay header +Recall that every relay cell has a stream ID in the relay header that indicates to which stream the cell belongs. This stream ID allows a relay cell to be addressed to any of the ORs @@ -710,9 +710,9 @@ Alice can instead send a relay truncate cell to a node along the circuit. That node will send a \emph{destroy} cell forward, and reply with an acknowledgment (a \emph{relay truncated} cell). Alice might truncate her circuit so she can extend it -to different nodes without signaling to the first few nodes (or somebody +to different nodes without signalling to the first few nodes (or somebody observing them) that she is changing her circuit. That is, nodes in the -middle of a truncated are not even aware when the circuit is +middle of a circuit are not even aware that the circuit has been truncated, because they see only the encrypted relay cells. Similarly, if a node on the circuit goes down, the adjacent node can send a \emph{relay truncated} cell back to @@ -964,6 +964,10 @@ require investigation. \SubSection{Exit policies and abuse} \label{subsec:exitpolicies} +%XXX originally, we planned to put the "users only know the hostname, +% not the IP, but exit policies are by IP" problem here too. Worth +% while still? -RD + Exit abuse is a serious barrier to wide-scale Tor deployment. Anonymity presents would-be vandals and abusers with an opportunity to hide the origins of their activities. Attackers can harm the Tor network by @@ -1857,7 +1861,7 @@ issues remaining to be ironed out. In particular: these bottlenecks. \item \emph{Cover traffic:} Currently we avoid cover traffic because of its clear costs in performance and bandwidth, and because its - security benefits have not well understood. With more research + security benefits are not well understood. With more research \cite{SS03,defensive-dropping}, the price/value ratio may change, both for link-level cover traffic and also long-range cover traffic. \item \emph{Better directory distribution:} Even with the threshold -- cgit v1.2.3