[tor-dev] Onion (Hidden) Service Proposal Discussion

[Tim Wilson-Brown - teor]

Hi,

We just had a meeting to discuss the following tor proposals[0] in the #tor-dev IRC channel[1].

Proposal 252: Single Onion Services
Proposal 260: Rendezvous Single Onion Services
Proposal 255: Controller features to allow for load-balancing hidden services
Proposal 246: Merging Hidden Service Directories and Introduction Points

A quick summary of each proposal:

Some onion (hidden) service websites don't need to hide their location.
They can have faster connection setup and bandwidth, and put less load on the tor network, by having 3 relays between the client and onion service.

Proposal 252 has the onion service open an ORPort, and then clients extend from their third relay to the ORPort.
Proposal 260 has the onion service connect directly to the introduction and rendezvous points.

The other proposals improve onion service speed in different ways:

Proposal 255 improves hidden or onion service load balancing by handing off the rendezvous to another tor instance.

Proposal 246 improves hidden or onion service setup time by using the HSDirs as introduction points, and teaching clients to re-use the HSDir connection for the introduction.

And a quick summary of our thoughts:

Proposal 252 and Proposal 260 achieve similar outcomes. 260 is simpler to code, preserves NAT-punching (which some website providers need), and has already been coded[2]. It's also compatible with 255, which 252 is not. But 252 has a faster connection set-up time, because it skips the rendezvous protocol entirely. We'd like to see more research into the performance differences between 252 and 260.

We want to focus on Proposal 224 (next-generation hidden services), and we were concerned that too much other work on onion service proposals would slow that down. So we'd like to finish 260 in the short term, and then reconsider 252 based on resourcing and research outcomes.

We thought that 255 was a good idea, but noted that it increases connection set-up time.

We noted that 246 already had concerns raised about it on the mailing list. That said, we could use 246 to improve the performance of 260.

Tim

[0]: https://gitweb.torproject.org/torspec.git/tree/proposals <https://gitweb.torproject.org/torspec.git/tree/proposals>
[1]: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-02-08-22.00.log.html <http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-02-08-22.00.log.html>
[2]: https://trac.torproject.org/projects/tor/ticket/17178 <https://trac.torproject.org/projects/tor/ticket/17178>


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/20160209/547b0f20/attachment-0001.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/20160209/547b0f20/attachment-0001.sig>