<div dir="ltr"><div class="gmail_default" style="font-size:small"><div class="gmail_default" style="color:rgb(0,0,0)">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.</div><div class="gmail_default" style="color:rgb(0,0,0)">A couple questions/comments:</div><div class="gmail_default" style="color:rgb(0,0,0);font-size:12.8000001907349px"><ul><li style="margin-left:15px">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.</li><li style="margin-left:15px">Removing rendezvous nodes is a<span style="font-size:12.8000001907349px"> bigger change to the protocol, but would be very useful</span>. 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 <font color="#000000">descriptor (this would conveniently identify the service as non-hidden, whether that's a good or bad thing...)</font></li></ul></div></div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">—————————<br><a href="https://jhaven.me/" target="_blank">Jacob H. Haven – https://jhaven.me/</a><br><a href="mailto:jacob@jhaven.me" title="[GMCP] Compose a new mail to jacob@jhaven.me" rel="noreferrer" target="_blank">jacob@jhaven.me</a><div><a href="mailto:jacob@cloudflare.com" target="_blank">jacob@cloudflare.com</a><br><a href="mailto:jhaven@cs.stanford.edu" title="[GMCP] Compose a new mail to jhaven@cs.stanford.edu" rel="noreferrer" target="_blank">jhaven@cs.stanford.edu</a><br><a value="+19494156469">+1-(949)-415-6469</a><br></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Apr 9, 2015 at 1:17 PM, David Goulet <span dir="ltr"><<a href="mailto:dgoulet@ev0ke.net" target="_blank">dgoulet@ev0ke.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 09 Apr (21:58:49), George Kadianakis wrote:<br>
> Hello,<br>
><br>
> I inline a proposal for Direct Onion Services. It's heavily based on<br>
> the "encrypted services" proposal of Roger, but I refined it, made it<br>
> more proposaley and enabled a few more optimizations. You can find the<br>
> original piece here:<br>
>          <a href="https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted-services.txt" target="_blank">https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted-services.txt</a><br>
><br>
> Feedback would be greatly appreciated.<br>
<br>
</span>First thanks for that! Really useful stuff.<br>
<span class=""><br>
><br>
> Here are some specific points that I would like help with:<br>
><br>
> - Should we require a specially compiled version of Tor to enable this<br>
>   feature? Like we do for tor2web mode? In this proposal, I didn't<br>
>   require any special compilation flags. I don't have strong opinions<br>
>   here.<br>
<br>
</span>IMO, I'm not sure this is useful. This feature requires prior knowledge<br>
of the HS operator to know what's a "Direct Onion Service" and decide<br>
that she wants that for her service. Thus, a torrc option seems enough.<br>
I don't see any reasons for this option that will limit deployment.<br>
<span class=""><br>
><br>
> - We really really need a better name for this feature. I decided to<br>
>   go with "Direct Onion Services" which is the one that the NRL people<br>
>   suggested here:<br>
>   <a href="https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html" target="_blank">https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html</a><br>
>   I'm not super happy with it, but I can't think of better ones myself.<br>
>   Here are some candidates:<br>
>        1 Way Anonymous Hidden Services<br>
>        Fast Onion Service<br>
>        Short-circuited Onion Services<br>
>        Fast-but-not-hidden Services<br>
<br>
</span>"Fast Onion-Space Service" was proposed by pfmbot on #tor-dev. I like it<br>
because it describes pretty much what it is and the acronym is FOSS. :)<br>
<span class=""><br>
><br>
> - We also need a better torrc option. If the name of this feature does<br>
>   not portray its dangers, then the torrc option should be a bit<br>
>   terrifying. That's why I went 'DangerousDirectOnionService' which I<br>
>   actually don't like at all. BTW, it's unclear whether this mailing<br>
>   list is the best place to brainstorm for names.<br>
<br>
</span>This one depends on the name quite heavily but I don't think we should<br>
have a scary name. Scary name seems to me they will simply bring more<br>
questions without context of the actual feature. What is "Dangerous"<br>
about this, why is it in Tor at all?... This could simply be resolved by<br>
clear and thorough documentation of the risks/benefits of the options.<br>
<br>
For instance, we could *not* put it in the default torrc file and thus<br>
will only be in the man page with *good* documentation. Like you said<br>
also in the proposal, a big warning is very important at boot.<br>
<br>
If it's off by default and not present in the torrc file, there are no<br>
reasons why someone would enable this just because it's says<br>
"DirectOnionServiceEnable". (Ok I might be an optimist but still, we are<br>
not that responsible for reckless HS operator ;)<br>
<br>
[snip]<br>
<span class=""><br>
><br>
> 3.2. One-hop circuits [ONEHOP]<br>
><br>
>   When in this mode, the onion service establishes 1-hop circuits to<br>
>   introduction and rendezvous points. The onion service SHOULD also<br>
>   ignore cannibalizable 3-hop circuits when creating such circuits.<br>
><br>
>   This looks like this for the rendezvous point case:<br>
><br>
>        |direct onion service| -> RP <- client middle <- client guard <- |client|<br>
><br>
>   This change allows greater speeds when establishing a hidden service<br>
>   circuit and reduces round-trip times. As a side-effect, busy onion<br>
>   services with this feature cause less damage to the rest of the<br>
>   network, since their traffic gets passed around less.<br>
<br>
</span>Would it be possible to drop the rendezvous part where the client could<br>
simply connect to the IP and then the circuit back to the HS would be<br>
used? (Though that would require that the client knows the HS it's<br>
trying to reach is a Direct Onion Service, could be mention in the<br>
descriptor?...)<br>
<br>
This idea ^ is mention in the Future section but why not using it? Too<br>
much of a change? Unknown anonymity implications?<br>
<br>
Cheers!<br>
<span class=""><font color="#888888">David<br>
</font></span><br>_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br></blockquote></div><br></div></div>