Proposal: Combine Introduction and Rendezvous Points

[Karsten Loesing]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Nick,

| Added as proposal 142.

Thanks!

| [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.]

Agreed!

What kind of security analysis would you expect here? What I usually do
is think about all kinds of attacks and argue whether or not they are
possible and what efforts it takes to conduct them. I can imagine that
this has little to do with what you would call a security analysis. So,
I'd like to learn more about this. Can you give me some pointers?

| This isn't "plausible deniability" [...]

Whoops. Did we call it plausible deniability?

The property behind it is a combination of two properties that Lasse and
Paul described in their PET 2007 paper. But the new property had no
name, so we gave it one, and this one appeared... well, plausible.

Sorry for the confusion, we can change that name. :)

| (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.

Good point. We'll analyze this one.

Maybe it's okay here to require a contact point to have both, high
uptime and bandwidth. I guess that there are so many relays out there
which are good candidates for contact points that we can be more picky
without risking to end up at the same relays all the time.

But that's just what I would expect, the statistics will tell us more.

| ... 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.

Hmm, I don't want to keep you from re-reading proposal 121. However, the
combination of introduction and rendezvous points (proposal 142) should
not be specific to hidden services with client authorization (proposal
121), but should benefit all hidden services.

| 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.

I'll write a draft rend-spec-v2.txt containing all the proposals
including the v2 hidden service directory specification after I have
sent you the remaining proposals for 0.2.1.x.

Thanks, Nick, for your comments---and your patience! :)

- --Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIZnUN0M+WPffBEmURAnmRAKCFkHcaJdFVxRp39EZt/J9y0TH4pgCeIxZ1
wvkQ1uBFV41t+gU+mkL5tqQ=
=2W6k
-----END PGP SIGNATURE-----