[tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

[str4d]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

George Kadianakis wrote:
> David Goulet <dgoulet at ev0ke.net> writes:
> 
>> On 09 Apr (21:58:49), George Kadianakis wrote:
>>> Hello,
>>> 
>>> I inline a proposal for Direct Onion Services. It's heavily 
>>> based on the "encrypted services" proposal of Roger, but I 
>>> refined it, made it more proposaley and enabled a few more 
>>> optimizations. You can find the original piece here: 
>>> https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/
>>>
>>> 
xxx-encrypted-services.txt
>>> 
>>> 
>>> 
>>> 
Feedback would be greatly appreciated.
>> 
>> First thanks for that! Really useful stuff.
>> 
>>> 
>>> Here are some specific points that I would like help with:
>>> 
>>> - Should we require a specially compiled version of Tor to 
>>> enable this feature? Like we do for tor2web mode? In this 
>>> proposal, I didn't require any special compilation flags. I 
>>> don't have strong opinions here.
>> 
>> IMO, I'm not sure this is useful. This feature requires prior 
>> knowledge of the HS operator to know what's a "Direct Onion 
>> Service" and decide that she wants that for her service. Thus, a
>>  torrc option seems enough. I don't see any reasons for this 
>> option that will limit deployment.
>> 
> 
> Yes, I also feel the same.
> 
> My main fear is sample torrc's that are being posted around the
> net and people just copy-paste them into their box: someone might
> not notice the DirectOnionServiceEnable option.

Perhaps this could be mitigated by alerting the user the first time
Tor is started with this option enabled. This is obviously harder to
do if Tor is started as a service, but it should be possible for
manually-started Tor or TBB.

>> 
>> [snip]
>> 
>>> 
>>> 3.2. One-hop circuits [ONEHOP]
>>> 
>>> When in this mode, the onion service establishes 1-hop circuits
>>> to introduction and rendezvous points. The onion service SHOULD
>>> also ignore cannibalizable 3-hop circuits when creating such
>>> circuits.
>>> 
>>> This looks like this for the rendezvous point case:
>>> 
>>> |direct onion service| -> RP <- client middle <- client guard 
>>> <- |client|
>>> 
>>> This change allows greater speeds when establishing a hidden 
>>> service circuit and reduces round-trip times. As a side-effect,
>>> busy onion services with this feature cause less damage to the
>>> rest of the network, since their traffic gets passed around
>>> less.
>> 
>> Would it be possible to drop the rendezvous part where the client
>> could simply connect to the IP and then the circuit back to the
>> HS would be used? (Though that would require that the client
>> knows the HS it's trying to reach is a Direct Onion Service,
>> could be mention in the descriptor?...)
>> 
> 
> I think that's indeed possible, but would require multiplexing 
> multiple client connections on a single IP circuit, which Tor 
> cannot do at the moment AFAIK. It is my understanding that it's not
> an easy change, but I'm pretty sure that I2P and other projects are
> doing it, so we could in theory take a look at how those guys do
> it.

I2P does have the ability to run "zero-hop" tunnels, yes - the router
simply provides its own details for the tunnel entry point. But this
probably isn't directly helpful for Tor because I2P is a
packet-switched network, and it doesn't use separate rendezvous points
for individual connections between Destinations.

For high-traffic services that don't require anonymity, we generally
recommend using one-hop tunnels instead of zero-hop. This is primarily
to avoid connection limits being exceeded on the hosting router. The
speed hit of having an additional hop in the path is generally
outweighed by the benefit of only having e.g. 8 incoming connections
for a particular service, instead of several thousand. It therefore
also helps to mitigate DDoS attacks (although the biggest of services
e.g. Facebook would likely have their own systems that would better
handle this).

str4d

> _______________________________________________ tor-dev mailing 
> list tor-dev at lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVKGTIAAoJEBO17ljAn7PgYg8P/1gn8BleY9GyuceCXCvVicwk
ROWeEahM/ujSzpJXqjTJMBjuBcXocan/RHbeTyrfjCGZhj4p/eUMKnXpMBpJcuKp
oKEDXP3n14tnUxTnUT7vRl4ZYGmCZAiIKUqeqwAz2/1LxKYK+IDsxaurnbOA5uXV
vuL2Q8WxbnhExEr+lvRX4zV2/5hGK7jj5R1Hz35qxZsJTjPUu3mRXxS5aiExUfzS
kjxUA5uevKdE6/K0nQ4hJ7rY3ZkfcD8YIsW7CQsC0FfK8DXMaPew+tvUsUuegeDt
nbIFRx8oGItFwDDwZIUWZED2g60YhrSc7Ig192amXYe42GtoPQC3n6ul0GqNM2cb
m5AJAw5GGlxluprAwu3AcVl3/kYCLqN50bK/Lz3f2bBcYuUvcbNJ5GK6F4W/ye45
Pl2QmiiaGuZM5CKWNY4/kHc3sJaPfnFvbxdocqcIok3/AlnhVotQVDTl7bFklYOP
qJ58oNJAU2UHY+uOX6c+8+d2G062AbWxo4iFlXOGguNSKnR+3w0fE+P+lMQjtAGj
cE/7zj/DcFrj9TpVoZBAiDrEJfkWxywASoHhe1Y/eayzDg1D/jqfNNJ9/0YnPWPd
tC/pnHPQ1/gc9mqIJzmW1c9tKdwzys1UI9UGNjdggVn80dnXYyE5xAwx5Ymh11NT
VzHWkgab7+Shrp4dQL3a
=B87T
-----END PGP SIGNATURE-----