Proposal: Combine Introduction and Rendezvous Points

[Nick Mathewson]

On Fri, Jun 27, 2008 at 03:54:59PM +0200, Karsten Loesing wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Nick, Roger, Lasse, Paul, and list,
> 
> Nick, you wanted to have the new proposals for 0.2.1.x in until end of
> June. This is the first out of three proposals that I think are worth
> considering for 0.2.1.x. This proposal is also quite important for the
> NLnet project, because it exhibits the potential for major performance
> improvements.

Added as proposal 142.

[As for getting this reviewed in time to get it merged into 0.2.1.x:
I'm not going to merge code for features without security analysis.
This analysis doesn't need to be done today or even by June 30, but it
needs to be done before the code hits trunk.]


>  There are some reasons for separating the two roles of introduction and
>  rendezvous point: (1) Plausible deniability: A relay shall not be made
>  responsible that it relays data for a certain hidden service; in the
>  original design as described in [1] an introduction point relays no
>  application data, and a rendezvous points neither knows the hidden
>  service nor can it decrypt the data.

This isn't "plausible deniability", and we certainly didn't use that
term in the paper.  It's originally from govermental agencies, and
meant something like, "lots of people will guess it was us, but there
had better not be any solid proof."  When it *is* used in security, it
means something pretty vague; usually along the lines of "just because
I've got this here steganography software doesn't mean I've actually
used it to hide anything in this here random-looking bitstream."

But this isn't what the IP/RP separation was meant to do.  The
security idea mentioned in [1] was to resist smear attacks (run a
really offensive service to make trouble for a given node for relaying
bits that service).  We thought it was important at the time; who
knows.

The property you're talking about above is that no relay is easily
linked with any with any particular hidden service.  This property
probably needs a name, but plausible deniability isn't it.

> (2) Scalability: The hidden service shall not have to maintain a
> number of open circuits proportional to the expected number of
> client requests. (3) Attack resistance: The effect of an attack on
> the only visible parts of a hidden service, its introduction points,
> shall be as small as possible.

(4) Separation of node properties.  Introduction points need to be up
a lot, but don't need much bandwidth.  Rendezvous points need
bandwidth, but are relatively ephemeral.  Likewise, we thought this
was important.  We should analyze whether it is.


... I've just given  the rest of the proposal a skim, and I think I
need to have another look once I've re-read proposal 121.

An idea from the #tor-dev channel: it's probably time to do for the
hidden service protocol what we did for the directory protocol, and
split the specification into rend-spec-v1.txt and rend-spec.txt, and
edit the latter to contain all these proposals once they're a little
more discussed.  Doing this for directory stuff helped identify places
that hadn't actually gotten specified in our proposals.

yrs,
-- 
Nick