[tor-dev] Proposal: Rendezvous Single Onion Services

[Roger Dingledine]

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 authorization mechanisms

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

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

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

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.

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

Thanks!
--Roger