[or-cvs] rewrite rendezvous spec so normal people can follow it

[Roger Dingledine]

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

Modified Files:
	rendezvous.txt 
Log Message:
rewrite rendezvous spec so normal people can follow it


Index: rendezvous.txt
===================================================================
RCS file: /home/or/cvsroot/doc/rendezvous.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- rendezvous.txt	14 Jun 2003 07:27:45 -0000	1.4
+++ rendezvous.txt	22 Jun 2003 10:33:21 -0000	1.5
@@ -1,22 +1,48 @@
-                  How to make rendezvous points work
-                               1-11Jun2003
+              How to make rendezvous points work with tor
 
 0. Overview
 
-   Rendezvous points are an implementation of server anonymity /
-   location-hidden servers in the onion routing network.  There are
-   three components needed for rendezvous points:
+   Rendezvous points are an implementation of location-hidden services
+   (server anonymity) in the onion routing network. Location-hidden
+   services means Bob can offer a tcp service (say, a webserver) via the
+   onion routing network, without revealing the IP of that service.
 
-   A) A means for the client ("Alice") to tell a server ("Bob") where
-      to contact her in order to establish a connection. (Introduction)
-   B) A means for Bob to contact Alice to actually establish the
-      connection, and for them to communicate later. (Meeting)
-   C) 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. (Application)
+   The basic idea is to provide censorship resistance for Bob by allowing
+   him to advertise a variety of onion routers as his public location
+   (nodes known as his Introduction Points, see Section 1). Alice,
+   the client, chooses a node known as a Meeting Point (see Section
+   2). This extra level of indirection is needed so Bob doesn't serve
+   files directly from his public locations (so these nodes don't 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'll tackle these in order.  In all cases, we'll assume that both
-   Alice and Bob run local OPs.
+   We also 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 3). Both Alice
+   and Bob must run local onion proxies (OPs).
+
+   The big picture follows. We direct the reader to the rest of the
+   document for more details and explanation.
+
+   1) Bob chooses some Introduction Points, and advertises them on a DHT.
+   2) Bob establishes onion routing connections to each of his
+      Introduction Points, and waits.
+   3) 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.
+   4) Alice chooses and establishes a Meeting Point for this transaction.
+   5) 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.
+   6) IP sends the blob to Bob.
+   7) Bob chooses whether to ignore the blob, or to onion route to MP.
+   8) 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.
+   9) 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.
+   10) Data goes back and forth as usual.
 
 1. Introduction service
 
@@ -27,11 +53,11 @@
 
    When establishing such an introduction point, Bob provides the onion
    router with a public "introduction" key.  The hash of this public
-   key uniquely identifies Bob, and prevents anybody else from
-   usurping Bob's introduction point in the future.  Additionally, Bob
-   can use the same public key to establish an introduction point on
-   another OR, and Alice can still be confident that Bob is the same
-   server.
+   key identifies a unique Bob, and (since Bob is required to sign his
+   messages) prevents anybody else from usurping Bob's introduction
+   point in the future.  Additionally, Bob can use the same public key
+   to establish an introduction point on another onion router (OR),
+   and Alice can still be confident that Bob is the same server.
 
    (The set-up-an-introduction-point command should come via a
    RELAY_BIND_INTRODUCTION cell. This cell creates a new stream on the
@@ -54,13 +80,12 @@
 [98 bytes] g^x part 1 (inside the RSA)
 [30 bytes] g^x part 2 (symmetrically encrypted)
 
-
    The meeting point and meeting cookie allow Bob to contact Alice and
-   prove his identity; the end-to-end authentication enables Bob to 
+   prove his identity; the end-to-end authentication enables Bob to
    decide whether to talk to Alice; the initial authentication enables
-   the meeting point to pre-screen introduction requests before
-   sending them to Bob.  (See 3 for a discussion of meeting points;
-   see 2.1 for a proposed authentication mechanism.)
+   the meeting point to pre-screen introduction requests before sending
+   them to Bob.  (See Section 2 for a discussion of meeting points;
+   see Section 1.1 for an example authentication mechanism.)
 
    The authentication steps are the appropriate places for the
    introduction server or Bob to do replay prevention, if desired.
@@ -82,6 +107,10 @@
 
    [Maybe] Each 'A' has an expiration time built in to it.
 
+   In reality, we'll want to pick a scheme that (a) wasn't invented from
+   scratch in an evening, and (b) doesn't require Alice to remember this
+   many bits (see section 3.2).
+
 2. Meeting points
 
    For Bob to actually reply to Alice, Alice first establishes a
@@ -130,21 +159,23 @@
    We assume the existence of a robust decentralized efficient lookup
    system (call it "DHT"). Bob publishes
      * Bob's Public Key for that service
-     * Timestamp
+     * Expiration date ("don't use after")
      * Introduction server 0 ... Introduction server N
      (All signed by Bob's Public Key)
    into DHT, indexed by the hash of Bob's Public Key. Bob should
    periodically republish his introduction information with a new
-   timestamp (and possibly with new/different introduction servers if
-   he wants), so Alice can trust that DHT is giving her an up-to-date
-   version.
+   expiration date (and possibly with new/different introduction servers
+   if he wants), so Alice can trust that DHT is giving her an up-to-date
+   version. The Chord CFS paper describes a sample DHT that allows
+   authenticated updating.
 
 3.2. Application interface: client side
 
    We require that the client interface remain a SOCKS proxy, and we
    require that Alice shouldn't have to modify her applications. Thus
-   we encode all of the necessary information into the hostname that
-   Alice uses (eg when clicking on a url in her browser, etc).
+   we encode all of the necessary information into the hostname (more
+   correctly, fqdn) that Alice uses, eg when clicking on a url in her
+   browser.
 
    To establish a connection to Bob, Alice needs to know an Introduction
    point, Bob's PK, and some authentication cookie. Because encoding this
@@ -161,7 +192,6 @@
    13 characters.
 
    Alice's onion proxy examines hostnames and recognizes when they're
-   destined for a hidden server. If so, it decodes the PK, looks it up in
-   the DHT, chooses and connects to a meeting place, chooses and connects
-   to one of Bob's introduction servers, and then waits to hear from Bob.
+   destined for a hidden server. If so, it decodes the PK and performs
+   the steps in Section 0 above.