[tor-dev] Alternate Single Onion Service Designs

[Tim Wilson-Brown - teor]

> On 7 Nov 2015, at 04:36, Alec Muffett <alecm at fb.com> wrote:
> 
> These three solutions in aggregate should lower latency and scale tor daemon bandwidth by a range of 18..60x
> 
> Then:
> 
> 4) (Wishlist) implementation of TVDW's handoff of RP callback
> 
> ...which will resolve any remaining CPU-bandwidth issues.
> 
> These plans are subject to change, but seem reasonable so far.

Rendezvous handoff is partially implemented in:
https://trac.torproject.org/projects/tor/ticket/17254 <https://trac.torproject.org/projects/tor/ticket/17254>

I think we're waiting on the following:
* a more detailed specification of the handoff data fields for current and next-generation onion services, so we can be sure it's future-proof (I believe this is the decrypted and parsed cell content)
* confirmation that the introduction-side will decrypt (and parse) the INTRODUCE2 cell, to avoid sending introduction point private keys over the control port (this puts slightly more load on the introduction point, but a single message compromise would only compromise that rendezvous, not all the rendezvous for that day from that introduction point)

Together, these two changes would also support the "rendezvous approver" control port feature, where the handoff controller can filter requests as needed based on their content or on external factors such as load.

This also might be a nice way of doing geographical load-balancing: an introduction for a European rendezvous point could be sent to a nearby European data center to perform the actual rendezvous. Alternately, it could be send to a lightly-loaded instance.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151107/8789c8b6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151107/8789c8b6/attachment.sig>