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

[George Kadianakis <desnacked@xxxxxxxxxx>]

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.

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.

- 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

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

Here goes proposal:

----

Filename: 244-direct-services.txt
Title: Direct Onion Services: Fast-but-not-hidden services
Author: Roger Dingledine, George Kadianakis
Created: 2011-01-12
Status: Draft

1. Motivation

  Hidden services can cover multiple use cases and threat models. They
  offer server-side anonymity by default because that's the most
  common use case, but there also hidden service users who don't
  really need service-side anonymity.

  This proposal aims to satisfy those users by introducing an optional
  opt-in feature that *sacrifices server-side anonymity* *for better
  performance*. Client-side anonymity will still be preserved as normal.

  Here are some use cases that this idea addresses:

  1) Indymedia wants to run an exit enclave that provides end-to-end
     authentication and encryption. They tried running an exit relay
     that just exits to themselves (#800) but
     * it handles lots of other traffic too since it's a relay
     * exit enclaves don't actually work consistently, because the
       first connection from the user doesn't realize it should use the
       exit enclave.

  2) Wikileaks uses Tor hidden services not to hide their service, but
     because the hidden service address provides a type of usability
     we didn't think much about: unlike a more normal address, a Tor
     hidden service address either works (meaning you get your
     end-to-end authentication and encryption) or it fails hard. With
     a hidden service address there's no way a user could accidentally
     submit their documents to Wikileaks without using Tor, but with
     normal Tor it's possible.

  3) The Freenode IRC network wants to provide end-to-end encryption
     and authentication to its users, a) to handle the fact that the
     IRC protocol doesn't really provide much of that by default, and
     b) to funnel all their Tor users into a single location so they
     can handle the anonymous users better. They don't mind the fact
     that their service is hidden, but they'd rather have better
     performance for their users given the choice.

  As a side-effect, by optimizing for performance in this feature, it
  allows us to lean more heavily towards security decisions for
  regular onion services.

2. Design

  We suggest the following changes to be implemented:

  i.   Add a way in the torrc file to specify that this service wants
       to be an encrypted service rather than a hidden service. [TORRC]

  ii.  An encrypted service SHOULD establish 1-hop circuits to its
       introduction points. [ONEHOP]

  iii. An encrypted service SHOULD establish 1-hop circuits to
       rendezvous points [ONEHOP].

  iv.  An encrypted service MAY NOT use static guard nodes [NOGUARDS].

  More information about these steps can be found in the next section.

3. Specification

3.1. Torrc configuration parameter [TORRC]

  To enable this optional feature, we introduce the boolean
  DangerousDirectOnionService torrc option. The option MUST be
  *disabled by default*.

  Because of the grave consequences of misconfiguration here, we have
  prepended the torrc option with 'Dangerous'. Furthermore, Tor MUST
  issue a startup warning message to operators of the hidden service
  if this feature is enabled.

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.

3.3. Disable guard nodes [NOGUARDS]

  Entry guards are a security measure against Sybil attacks.
  Unfortunately, they also act as the bottleneck of busy hidden
  services and overload those Tor relays.

  This proposal suggests disabling the entry guard feature entirely
  when this mode is enabled. This allows the hidden service to split
  its traffic out to multiple relays on the network.

4. Security implications

  There's a possible second-order effect here since both encrypted
  services and hidden services will have foo.onion addresses and it's
  not clear based on the address whether the service will be hidden --
  if *some* .onion addresses are easy to track down, are we encouraging
  adversaries to attack all rendezvous points just in case?

5. Future

  Here are some thoughts on things we could look in the future to
  further optimize performance when this mode is enabled:

  - We should look whether we can optimize further the preemptive
    circuits that Tor makes as a hidden service.

  - We could also make hidden services determine the number of
    introduction points based on their popularity, to allow greater
    load balancing. This has the potential for leaking the popularity
    of hidden services (#4862), but maybe this is not a concern when
    this mode is enabled.

  - For this mode, we could look into alternative designs where a
    rendezvous step is not needed, and the traffic gets routed through
    the introduction points (as in Valet nodes [0]).

[0]: http://freehaven.net/anonbib/#valet:pet2006
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev