remove obsolete rendezvous pre-spec

svn:r1886

doc/rendezvous.txt

@@ -1,200 +0,0 @@
-                   How to make rendezvous points work
-
-0. Overview
-
-   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.
-
-   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 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) -- software that knows
-   how to talk to the onion routing network.
-
-   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
-      Distributed Hash Table (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. The Introduction Point sends the blob to Bob.
-   6) Bob chooses whether to ignore the blob, or to onion route to MP.
-      Let's assume the latter.
-   7) 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.
-   8) 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.
-   9) Data goes back and forth as usual.
-
-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 an introduction point, Bob provides the onion
-   router with a public "introduction" key.  The hash of this public
-   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
-   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 introduction port, and
-   sends the following:
-
-     MEETING REQUEST
-        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 introduction 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.
-
-   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.
-
-1.1. An example authentication scheme for introduction services
-
-   Bob makes two short-term secrets SB and SN, and tells the
-   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>.
-
-   [Maybe] Bob keeps a replay cache of A values, and doesn't allow any
-   value to be used twice.  Over time, Bob rotates SB and SN.
-
-   [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
-   circuit to an onion router R, and sends a RELAY_BIND_MEETING cell
-   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.  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,
-   RELAY_END, and RELAY_SENDME cells from Bob.  All RELAY_BEGIN cells
-   to Bob must have target IP and port of zero; Bob's OP will redirect
-   them to the actual target IP and port of Bob's server.
-
-   Alice and Bob's OPs disallow CREATE or RELAY_EXTEND cells as usual.
-
-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" for distributed hash table -- note that the
-   onion routers can run nodes). Bob publishes
-     * Bob's Public Key for that service
-     * 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
-   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 (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
-   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). Location-hidden
-   services use the special top level domain called '.onion': thus
-   hostnames take the form x.y.onion where x is the hash of PK, and y
-   is the authentication cookie. If no cookie is required, the hostname
-   can simply be of the form x.onion. Assuming only case insensitive
-   alphanumeric and hyphen, we get a bit more than 6 bits encoded
-   per character, meaning the x part of the hostname will be about
-   13 characters.
-
-   Alice's onion proxy examines hostnames and recognizes when they're
-   destined for a hidden server. If so, it decodes the PK and performs
-   the steps in Section 0 above.
-