> On Nov 6, 2015, at 4:56 PM, teor <teor2...@gmail.com> wrote: > Do we need both single onion services (Proposal 252) and rendezvous single > onion services?
I would say they are both desirable, and that we could/should have both. RSOS is great for adoption, the rendezvous step enables NAT-punching and yet lowers latency. The NAT-punching is particularly desirable where - like in our configuration - the tor daemon resides in a DMZ enclave without inbound connectivity. See diagram at: https://twitter.com/dcuthbert/status/573197027242315776/photo/1 Source: https://storify.com/AlecMuffett/tor-tips RSOS thereby also offers a easy, nearly-no-rearchitecture-required route to enterprise deployment. Also RSOS enables OnionBalance, and other performance hacks such as those proposed by Tom van der Woerdt (https://lists.torproject.org/pipermail/tor-dev/2015-October/009618.html) all without requiring broad changes to deployed Tor daemons SOS by comparison sounds best where pure performance matters, but I am not sure how the other scaling solutions will fit into it; but pure performance matters a lot, so overall I think I’d like to see both. My plans for Onion scaling are approximately as follows: 1) Remove unnecessary privacy hops / deploy RSOS (in progress) 2) OnionBalance: Merge introduction points (IPs) from multiple daemons into one descriptor (possible issue: there is a hardcoded limit of 3x IPs?) 3) Steven Murdoch / Ceysun Sucu research: Implement distinct OnionBalance descriptors at each (6?) point on the HSDir ring These three solutions in aggregate should lower latency and scale tor daemon bandwidth by a range of 18..60x Then: 4) (Wishlist) implementation of TVDW's handoff of RP callback ...which will resolve any remaining CPU-bandwidth issues. These plans are subject to change, but seem reasonable so far. - alec > 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@lists.torproject.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.torproject.org_cgi-2Dbin_mailman_listinfo_tor-2Ddev&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=T4UdyZF0g0I68UQdhjA_7A&m=39qCF0WwsOlclgI4JLpSsdoQf3OFoAoioXMj3Yl9cSo&s=62XIjIsvN1QdwcbCz2d3zq1T9iYCDY5GVPmORfbvhKU&e=
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
