another revision of the rendezvous spec

this time the application-side behavior is more plausible


svn:r317

1 files changed, 100 insertions, 74 deletions

diff --git a/doc/rendezvous.txt b/doc/rendezvous.txt
index b1ef97b56..ab0239167 100644
--- a/doc/rendezvous.txt
+++ b/doc/rendezvous.txt
@@ -1,80 +1,79 @@
                   How to make rendezvous points work
                                1-11Jun2003
 
-1. Overview
-
-   This document provides a design overview for rendezvous points, as
-   discussed by Nick and Roger after Discex.  
+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:
 
    A) A means for the client ("Alice") to tell a server ("Bob") where
-      to contact her in order to establish a connection.  (Notification)
+      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)
 
-   We'll tackle these in order.  In all cases, I'll assume that both
-   Alice and Bob have local OPs.
+   We'll tackle these in order.  In all cases, we'll assume that both
+   Alice and Bob run local OPs.
 
-2. Notification service
+1. Introduction service
 
    Bob wants to learn about client requests for communication, but
    wants to avoid responding unnecessarily to unauthorized clients.
    Bob's proxy opens a circuit, and tells some onion router on that
    circuit to expect incoming connections, and notify Bob of them.
 
-   When establishing such a notification point, Bob provides the onion
-   router with a public "notification" key.  The hash of this public
+   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 notification point in the future.  Additionally, Bob
-   can use the same public key to establish a notification point on
+   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.
-  
-   (The set-up-a-notification-point command should come via a
-   RELAY_BIND_NOTIFICATION cell. This cell creates a new stream on the
-   circuit from Bob to the notification point.)
 
-   ORs that support notification run a notification service on a
+   (The set-up-an-introduction-point command should come via a
+   RELAY_BIND_INTRODUCTION cell. This cell creates a new stream on the
+   circuit from Bob to the introduction point.)
+
+   ORs that support introduction run an introduction service on a
    separate port.  When Alice wants to notify Bob of a meeting point,
-   she connects (directly or via Tor) to the notification port, and
+   she connects (directly or via Tor) to the introduction port, and
    sends the following:
-   
+
      MEETING REQUEST
-        Encrypted with server's public key:
-           Hash of Bob's public key (identifies which Bob to notify)
-           Initial authentication [optional]
-        Encrypted with Bob's public key:
-           Meeting point
-           Meeting cookie
-           End-to-end forward key
-	   End-to-end backward key
-           End-to-end authentication [optional]
-           
-   [Add a Nonce or some kind of replay prevention mechanism? -NM]
-   [Should this use DH instead? -NM]
+        RSA-OAEP encrypted with server's public key:
+[20 bytes] Hash of Bob's public key (identifies which Bob to notify)
+[ 0 bytes] Initial authentication [optional]
+        RSA encrypted with Bob's public key:
+[16 bytes] Symmetric key for encrypting blob past RSA
+[ 6 bytes] Meeting point (IP/port)
+[ 8 bytes] Meeting cookie
+[ 0 bytes] End-to-end authentication [optional]
+[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 
    decide whether to talk to Alice; the initial authentication enables
-   the meeting point to pre-screen notification requests before
+   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.)
 
-   When the notification point receives a valid meeting request, it
-   sends the portion encrypted with Bob's public key along the stream
-   created by Bob's RELAY_BIND_NOTIFICATION.  Bob then, at his
+   The authentication steps are the appropriate places for the
+   introduction server or Bob to do replay prevention, if desired.
+
+   When the introduction point receives a valid meeting request, it
+   sends the portion intended for Bob along the stream
+   created by Bob's RELAY_BIND_INTRODUCTION.  Bob then, at his
    discretion, connects to Alice's meeting point.
 
-2.1. Proposed authentication for notification services
+1.1. An example authentication scheme for introduction services
 
    Bob makes two short-term secrets SB and SN, and tells the
-   notification point about SN.  Bob gives Alice a cookie consisting
+   introduction point about SN.  Bob gives Alice a cookie consisting
    of A,B,C such that H(A|SB)=B and H(A|SN)=C.  Alice's initial
    authentication is <A,C>; Alice's end-to-end authentication is <A,B>.
 
@@ -83,25 +82,24 @@
 
    [Maybe] Each 'A' has an expiration time built in to it.
 
-3. Meeting points
+2. Meeting points
 
    For Bob to actually reply to Alice, Alice first establishes a
    circuit to an onion router R, and sends a RELAY_BIND_MEETING cell
-   to that onion router.  The RELAY_BIND_MEETING cell contains a 
+   to that onion router.  The RELAY_BIND_MEETING cell contains a
    'Meeting cookie' (MC) that Bob can use to authenticate to R.  R
    remembers the cookie and associates it with Alice.
 
-   Later, Bob also routes to R and sends R a RELAY_JOIN_MEETING cell
-   with the meeting cookie MC.  After this point, R routes all traffic
-   from Bob's circuit or Alice's circuit as if the two circuits were
-   joined: any RELAY cells that are not for a recognized topic are
-   passed down Alice or Bob's circuit.
-   
-   To prevent R from reading their traffic, Alice and Bob use the two
-   end-to-end keys in Alice's original notification to Bob: Bob uses
-   the 'forward' key and Alice the 'backward' key.  (These keys are
-   used in addition to the series of encryption keys already in use on
-   Alice and Bob's circuits.)
+   Later, Bob also routes to R and sends R a RELAY_JOIN_MEETING cell with
+   the meeting cookie MC.  After this point, R routes all traffic from
+   Bob's circuit or Alice's circuit as if the two circuits were joined:
+   any RELAY cells that are not for a recognized topic are passed down
+   Alice or Bob's circuit.  Bob's first cell to Alice contains g^y.
+
+   To prevent R from reading their traffic, Alice and Bob derive two
+   end-to-end keys from g^{xy}, and they each treat R as just another
+   hop on the circuit.  (These keys are used in addition to the series
+   of encryption keys already in use on Alice and Bob's circuits.)
 
    Bob's OP accepts RELAY_BEGIN, RELAY_DATA, RELAY_END, and
    RELAY_SENDME cells from Alice.  Alice's OP accepts RELAY_DATA,
@@ -111,28 +109,56 @@
 
    Alice and Bob's OPs disallow CREATE or RELAY_EXTEND cells as usual.
 
-4. Application interface
-
-4.1. Application interface: client side
-
-   Because we require that the client interface remain a SOCKS proxy,
-   we can't have clients explicitly connect to Bob.  Instead, we have
-   the OP map DNS addresses used by the client to the
-       <Notification point, Bob's PK, Authentication> 
-   tuples needed to establish a connection to Bob.
-
-   [We had earlier hoped encode this information into the DNS address,
-    but that won't work.  The data needed will be at least ~1024 bits
-    long (for Bob's public key).  You'd need over 197 characters to
-    encode a blob that long, and you'd wind up triggering pathological
-    cases in a lot of client code. -NM]
-
-   I propose that the client OP receive this mapping information
-   outside of the Tor protocol: either from true out-of-band entry, or
-   from protocol-specific transmission.
-
-   (For example of protocol-specific, an HTTP server could include
-   notification information in reply headers, or cookies, or
-   something.)
-
+3. Application interface
+
+3.1. Application interface: server side
+
+   Bob has a service that he wants to offer to the world but keep its
+   location hidden.  He configures his local OP to know about this
+   service, including the following data:
+
+     Local IP and port of the service
+     Strategy for choosing introduction points
+       (for now, just randomly pick among the ORs offering it)
+     Strategy for user authentication
+       (for now, just accept all users)
+     Public (RSA) key (one for each service Bob offers)
+
+   Bob chooses a set of N Introduction servers on which to advertise
+   his service.
+
+   We assume the existence of a robust decentralized efficient lookup
+   system (call it "DHT"). Bob publishes
+     * Bob's Public Key for that service
+     * Timestamp
+     * 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.
+
+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).
+
+   To establish a connection to Bob, Alice needs to know an Introduction
+   point, Bob's PK, and some authentication cookie. Because encoding this
+   information into the hostname will be too long for a typical hostname,
+   we instead use a layer of indirection. We encode a hash of Bob's PK
+   (10 bytes is sufficient since we're not worrying about collisions),
+   and also the authentication token (empty for now). Thus at a bit more
+   than 6 bits encoded per character (assuming only alphanumeric and
+   hyphen), we transform the hostname "moria.mit.edu" into the hostname
+   "moria.mit.edu.onion5gfmjsda-ckd5" (adding 13 characters plus the
+   separator).
+
+   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.