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

Fri Apr 10 03:33:07 UTC 2015

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/ <https://jhaven.me/>
jacob at jhaven.me
jacob at cloudflare.com
jhaven at cs.stanford.edu
+1-(949)-415-6469

On Thu, Apr 9, 2015 at 1:17 PM, David Goulet <dgoulet at ev0ke.net> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150409/06b2c1ae/attachment.html>