[tor-dev] Alternate Single Onion Service Designs

[teor <teor2345@xxxxxxxxx>]

Hi all,

Do we need both single onion services (Proposal 252) and rendezvous single onion services?
We want to enable secure usage by default, and avoid splitting anonymity sets. But we also want to support real-world use cases, because anonymous protocols are safer if more people use them.

There are currently two different proposed single onion service designs:
* Single Onion Services (SOS - Proposal 252): require an ORPort, no introduction/rendezvous, one-hop extend
* Rendezvous Single Onion Services (RSOS - No Proposal Number): introduction/rendezvous with one-hop paths

I see at least the following scenarios for using these alternate single onion service designs:

0. an onion service operator who wants to minimise latency and maximise bandwidth runs a SOS (a RSOS is slower to connect due to the rendezvous protocol)

1. an onion service operator runs a SOS for new clients, and an RSOS for old clients (a RSOS is compatible with current clients, a SOS Is not)

2. an onion service operator who canât expose an ORPort runs a RSOS for all clients (there are enclave and NAT configurations where external ports are an issue)

3. an onion service operator who wants to use Proposal 255 for load-balancing runs a RSOS, and splits their introduction and rendezvous instances by passing the introduction over the control port (proposal 255 relies on the rendezvous protocol to handoff the rendezvous point connection to another Tor instance)

4. an onion service wants low latency and better bandwidth, and doesn't want to wait until the SOS feature is developed and deployed (SOS is a larger feature, and it needs client changes). They'll switch to SOS when it's well supported by installed versions of Tor Browser.

Given these use cases, I think we could implement both flavours of single onion service. But this splits the onion service anonymity set at least 3 ways (and maybe also by some other onion service features). I'm not sure how much of an impact this will have - it does depend on our threat model for each flavour of onion service.

If we wanted to generate more onion service cover traffic, we could move various automated Tor Browser actions (such as update checks and update downloads) to appropriate flavours of onion service. This would shift load away from exits, and also have address authentication benefits. (Tor Browser wouldn't have to rely on DNS, CA certificates, and SSL for Its updates.)

The other mitigations I'm aware of are cover traffic and lookalike protocol interactions, but these require significant research and design work.

We're working on implementing rendezvous single onion services in #17178. I think they're pretty close: we need to do some more testing, and handle some edge cases. RSOS servers work with existing clients, including current Tor Browser releases.

Single onion services (Proposal 252) is a larger feature, so it's a bit further away. SOS are incompatible  with current clients, so supporting code will need to be deployed in Tor clients (such as Tor Browser) as well as on the onion service itself. After the feature is ready, there will be some lead time before SOS are usable with the majority of deployed Tor clients.

What do you think?
Are onion services big enough to safely have multiple flavours?
Could they get that big if we support enough functionality?
Or are we better to implement secure, one-size-fits-all defaults, and ask users and operators to sacrifice some performance?

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev