put the appendix on its own page; make it only one page

\bibliographystyle{latex8}

\bibliography{tor-design}

\newpage

\appendix

\Section{Rendezvous points and hidden services}

\label{sec:rendezvous-specifics}

In this appendix we provide more specifics about the rendezvous points

of Section~\ref{subsec:rendezvous}. We also describe integration

issues and related work.

In this appendix we provide specifics about the rendezvous points

of Section~\ref{subsec:rendezvous}. % We also describe integration

%issues and related work.

%, and how well the rendezvous point design

%withstands various attacks.

%    (Not any more; it's currently commented out. -NM)

\SubSection{Rendezvous protocol overview}

We give an overview of the steps of a rendezvous. These are

%

%\SubSection{Rendezvous protocol overview}

%

The following steps are

%We give an overview of the steps of a rendezvous. These are

performed on behalf of Alice and Bob by their local OPs;

application integration is described more fully below.

entry in the DHT.

The message that Alice gives

the introduction point includes a hash of Bob's public key to identify

the service, along with an optional initial authorization token (the

the introduction point includes a hash of Bob's public key % to identify

%the service, along with 

and an optional initial authorization token (the

introduction point can do prescreening, for example to block replays). Her

message to Bob may include an end-to-end authorization token so Bob

can choose whether to respond.

The authorization tokens can be used to provide selective access:

important users get tokens to ensure uninterrupted access to the

service. During normal situations, Bob's service might simply be offered

important users can get uninterrupted access.

%important users get tokens to ensure uninterrupted access. %to the

%service.

During normal situations, Bob's service might simply be offered

directly from mirrors, while Bob gives out tokens to high-priority users. If

the mirrors are knocked down,

%by distributed DoS attacks or even

those users can switch to accessing Bob's service via

the Tor rendezvous system.

Since Bob's introduction points might themselves be subject to DoS he

could have to choose between keeping many

introduction connections open or risking such an attack. In this case,

he can provide selected users

with a current list and/or future schedule of introduction points that

are not advertised in the DHT\@. This is most likely to be practical

Bob's introduction points are themselves subject to DoS---he must

open many introduction points or risk such an attack.

He can provide selected users with a current list or future schedule of

unadvertised introduction points;

this is most practical

if there is a stable and large group of introduction points

available. Alternatively, Bob could give secret public keys

to selected users for consulting the DHT\@. All of these approaches

have the advantage of limiting exposure even when

some of the selected users collude in the DoS\@.

available. Bob could also give secret public keys

for consulting the DHT\@. All of these approaches

limit exposure even when

some selected users collude in the DoS\@.

\SubSection{Integration with user applications}

into the fully qualified domain name Alice uses when establishing her

connection. Location-hidden services use a virtual top level domain

called {\tt .onion}: thus hostnames take the form {\tt x.y.onion} where

{\tt x} is the authorization cookie, and {\tt y} encodes the hash of

{\tt x} is the authorization cookie and {\tt y} encodes the hash of

the public key. Alice's onion proxy

examines addresses; if they're destined for a hidden server, it decodes

the key and starts the rendezvous as described above.

trackers~\cite{federrath-ih96,reed-protocols97}.  Rendezvous for

low-latency

Internet connections was suggested in early Onion Routing

work~\cite{or-ih96}; however, the first published design of rendezvous

points for low-latency Internet connections was by Ian

work~\cite{or-ih96}, but the first published design was by Ian

Goldberg~\cite{ian-thesis}. His design differs from

ours in three ways. First, Goldberg suggests that Alice should manually

hunt down a current location of the service via Gnutella; our approach

makes lookup transparent to the user, as well as faster and more robust.

Second, in Tor the client and server negotiate session keys

via Diffie-Hellman, so plaintext is not exposed even at the rendezvous point. Third,

our design tries to minimize the exposure associated with running the

our design minimizes the exposure from running the

service, to encourage volunteers to offer introduction and rendezvous

point services. Tor's introduction points do not output any bytes to the

services. Tor's introduction points do not output any bytes to the

clients; the rendezvous points don't know the client or the server,

and can't read the data being transmitted. The indirection scheme is

also designed to include authentication/authorization---if Alice doesn't