[tor-dev] Alternate Single Onion Service Designs

[s7r]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi teor,

I like RSOS more and it removes 2 hops from a circuit which is quite A
LOT. This is a significant step for operators that require latency.
RSOS combined with OnionBalance or rendezvous approval feature which
will allow scaling beyond what's needed in most cases.

Also, RSOS is compatible with clients, the overall design is well
studied and very much improved over time, provides free easy NAT
punching (very useful) and doesn't bare all the requirements and
attack surface of a SOS.

I am happy having more and more services available via hidden services
- - I think it wisely uses the surplus middle:exit ratio in the network,
so having many options to offer to operators (RSOS, rendezvous
approval, OnionBalance, SOS, etc.) is very good.


On 11/6/2015 6:56 PM, teor wrote:
> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWPkq1AAoJEIN/pSyBJlsRxysIAM6GMNli5/CIJfugs1dFJz8S
94r0ezJnid/DZhEWfP40ywVNb2iJZOYUma6JE0XPS8lOatsJCE6wkWvx9a2tLouM
pIepDsAY0cONwklIEnASIywcaAB5a5lrklFCU3gHQ3WX+1w0UxHn1QhUZUdoZaxe
SjE4u6HLG/Be3Ooqp33y/uFd4RkJcZguZBDhOUBtCGfSLWLb2QfnCGgqXmhxZ9n3
guO6R/dVn7Qu1XOLq6n+OpJhUc5BkUx+H+p+OXfvN0f3x2Q4aWVjRLZOz2/A3Wy5
Ob/jUcdyjL+Odi8vJsmb0Ix/Qas6tTazHTC8CdX7vtzhvX5OJKpsui4VKTXoTlA=
=xSVM
-----END PGP SIGNATURE-----