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

[David Goulet]

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.

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

> 
> - 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 ;)

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

This idea ^ is mention in the Future section but why not using it? Too
much of a change? Unknown anonymity implications?

Cheers!
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150409/73ea5081/attachment-0001.sig>