Re: [tor-dev] Proposal: Rendezvous Single Onion Services

On 12 Feb 2016, at 15:57, Roger Dingledine <arma@xxxxxxx> wrote:

I made some hopefully uncontroversial changes to the proposal in
git, but here are the comments that you might want to think about or
disagree with before acting on. :)

On Fri, Oct 23, 2015 at 01:54:50AM +1100, Tim Wilson-Brown - teor wrote:
  Rendezvous single onion services have a few benefits over single onion
  services:

     * A rendezvous single onion service can load-balance over multiple
       rendezvous backends (see proposal #255)
     * A rendezvous single onion service doesn't need an accessible ORPort
       (it works behind a NAT, and in server enclaves that only allow
       outward connections)

       * A rendezvous single onion service can use the existing onion
         service authorisation mechanisms

Yes, true.

     * A rendezvous single onion service is compatible with existing tor
       clients, hidden service directories, introduction points, and
       rendezvous points
[...]
5. Publishing a rendezvous single onion service

  To act as a rendezvous single onion service, a tor instance (or cooperating
  group of tor instances) must:

     * Publish onion descriptors in the same manner as any onion service,
       using three-hop circuits. This avoids service blocking by IP address,
       proposal #224 (next-generation hidden services) avoids blocking by
       onion address.

Is this last part true? I think it isn't? If you know the onion address,
you can look at a 224-style descriptor and check if it corresponds to
that onion address.

You're right, it's not true. We hide the onion address only from those who *don't* know it.

5.1.3 Recommended Additional Options: Performance

     LongLivedPorts
       The default LongLivedPorts setting creates additional, unnecessary
       connections. This specifies no long-lived ports (the empty list).

Why specify this part? Is there much harm in leaving Tor to make a few
circuits here and there?

We decided not to implement this in Tor.

Operators running hundreds of RSOS instances may wish to add this to the config to avoid building extra circuits.

7. Considerations

Is it worthwhile to add a security note about the new surface area
we're giving the client, by letting it ask the RSOS to extend to
arbitrary destinations? I am thinking #17788.

Yes, we only discovered this issue after the proposal was written, and we've been working through the implications since then.

More generally, I wonder if the denial-of-service and similar "you can
make it open new connections" risk is symmetric to the proposal 252 design
(that is, you get the same dangers whether it's an external connection
coming in to the HS, or the HS making a connection out), or if there's
some meaningful difference. For example, I was thinking about sending
an intro request that specifies a particular relay, but with a different
identity fingerprint in the intro cell, thus forcing the HS to establish
a growing number of non-canonical OR conns. I think that particular
attack wouldn't work, but I wonder if there are others that would.

We need to think about this a bit more.

9. Further Work

Further proposals or research could attempt to mitigate the anonymity-set
splitting described in section 8. Here are some initial ideas.

I suggest splitting this whole section 9 into a separate proposal. It
seems to be about making it harder to distinguish whether a Tor
connection you're observing is being used for an onion service or a
normal (exit) connection -- for example, to stymie attacks like the
"Circuit Fingerprinting Attacks" from the Usenix Security '15 paper. I
think that is a totally different topic than RSOS.