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

Optimizations like these are really what help make onion services performant. With the right architecture I think they can be much faster and more secure thanÂregular non-onion (i.e. exit-node routed) sites.

A couple questions/comments:

What is the exact need for introduction points here at all? The onion service can just act as it's own introduction point(s), advertising its IPs to the HSDirs. They're possibly useful for load-balancing, but that can be achieved easier without these additional, third-party relays.
RemovingÂrendezvous nodes is aÂbigger change to the protocol, but would be very useful. Why not enable the client to just directly establish circuit(s) directly to theÂonion service? As David pointed out, this would probably be implemented most cleanly with a tag in the HSDirÂdescriptor (this would convenientlyÂidentify the service as non-hidden, whether that's a good or bad thing...)

âââââââââ
Jacob H. Haven â https://jhaven.me/
jacob@xxxxxxxxx

jacob@xxxxxxxxxxxxxx
jhaven@xxxxxxxxxxxxxxx
+1-(949)-415-6469

On Thu, Apr 9, 2015 at 1:17 PM, David Goulet <dgoulet@xxxxxxxxx> wrote:

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

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev