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

[George Kadianakis]

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.

>> 
>> - We really really need a better name for this feature. I decided to
>>   go with "Direct Onion Services" which is the one that the NRL people
>>   suggested here:
>>   https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html
>>   I'm not super happy with it, but I can't think of better ones myself.
>>   Here are some candidates: 
>>        1 Way Anonymous Hidden Services
>>        Fast Onion Service
>>        Short-circuited Onion Services
>>        Fast-but-not-hidden Services
>
> "Fast Onion-Space Service" was proposed by pfmbot on #tor-dev. I like it
> because it describes pretty much what it is and the acronym is FOSS. :)
>

It's not clear to me why acronym collisions are a plus :)

>> 
>> - We also need a better torrc option. If the name of this feature does
>>   not portray its dangers, then the torrc option should be a bit
>>   terrifying. That's why I went 'DangerousDirectOnionService' which I
>>   actually don't like at all. BTW, it's unclear whether this mailing
>>   list is the best place to brainstorm for names.
>
> This one depends on the name quite heavily but I don't think we should
> have a scary name. Scary name seems to me they will simply bring more
> questions without context of the actual feature. What is "Dangerous"
> about this, why is it in Tor at all?... This could simply be resolved by
> clear and thorough documentation of the risks/benefits of the options.
>
> For instance, we could *not* put it in the default torrc file and thus
> will only be in the man page with *good* documentation. Like you said
> also in the proposal, a big warning is very important at boot.
>
> If it's off by default and not present in the torrc file, there are no
> reasons why someone would enable this just because it's says
> "DirectOnionServiceEnable". (Ok I might be an optimist but still, we are
> not that responsible for reckless HS operator ;)

Yes, I agree that the 'Dangerous' prefix is stupid. I think I'm OK
with changing the proposal to use 'DirectOnionServiceEnable' but I would
prefer if it's a bit more alarming.

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