Re: [tor-talk] [Cryptography] Implementing full Internet IPv6 end-to-end encryption based on Cryptographically Generated Address

On 1/24/19, Alec Muffett wrote:

On Thu, 24 Jan 2019 at 19:33, grarpamp wrote:

...

As readers may be aware, Tor has an interesting capability via OnionCat and OnionVPN ... There's an open project for anyone who wants it... To bring IPv6 over v3 onions to Tor.

I'm wondering: could you please expand upon how this compares in importance to simply promoting the native adoption of Tor v3 Onion Networking, amongst the community of tool-developers and tool-users whom you envision the above solution (OnionCat/OnionVPN/IP-routing) benefitting?

As before, yes v3 is a great update, useful for many, even indeed properly set for users by default. But not for all users, as some may explicitly choose to trade features of one version, say v3, for long term capabilities still needed from, or only present for the future in, another version, say v2. v3 should be "promoted", yet that shouldn't be at expense or exclusive to anything else, nor should anything else be diminishing to it. Modularity works there. And since v3 is now the default, the low cost work of "promoting" it is now more or less done. So perhaps v3 can be set aside on its own for now to consider what "native" might mean in larger context... Killing v2, while at the same time not working on porting the curious IPv6 feature to vN, would be a foot shooting regression upon the future. While easy way out for some to propose, it's probably not the right approach. Maybe yes it's about tool devs and users... about apps... how to see folks using crypto privacy currency overlays messaging etc, more or less seamlessly, being protected from surveillance and censorship and enjoying free speech, scalable production class networks... do you... a) Wait forever until some critical number or combination of overlay networks and new apps, necessarily specifically exclusively and natively written for those nets alone... is reached, having mass effect at that point... or b) Try to provide extension API's for your overlay of the year that works with whatever apps people are already using today, and provide interop API's between overlays, until some overlays prove resistant enough for general usage tomorrow. (Recall that tor still emits an adversary warning on startup and has entire classes of unsolved weaknesses, as with any other overlay today.) Or elements of both and add win from both ends. Or something else or more. Historically, most overlays have failed at (a) because native never widely happened, and because of failing at (b), along with not yet having sufficient attack resistance, and plain old tunnel vision competition in narrow and easier fields (say delivering a message)... perhaps are missing out on some adoption wins in areas where they are actually suitable enough. IPv6 is a potential already "native" area here... Pick any list of "end user" or "server" applications, generally any IP capable thing out there that people plug into the internet (these days most everything is becoming IPv6 capable so let's just forget about IPv4). Well, the millions of apps out there all speak IP, and do not speak end to end bidirectional onion or i2p or anything else, let alone ride on or utilize any auth or uniqueness expectations therein. Yes, various LD_PRELOAD and packet filter torifying methods covers some things as a hack. However the problem is most apparent with apps that include addressing info in their data not just use it only for binding the network stack. Or that use anything other than TCP. Or that need to route, P2P, DHT, etc. Features break or the app simply won't work. Bittorrent is one such very popular application, many more exist, or could exist. Many of which might need to make use of addressing in data to scale, or UDP for efficiency or mixing. Further, trying to plug apps into these overlays is complex and thereby offputting and risky for all but expert users and admins. Now if you had some simple range of IPv6 for them to bind to and filter, or even an AF_WIDE, that becomes a lot easier to adopt and manage as well. And of course AF_WIDE, or AF_OVERLAY, though it would require code in all apps, would be a third party supportable modular library once plugged in as a compile option to the thousands of popular apps out there. Engineer something like that and magic starts to happen. Or since IPv6, crypto, networks, apps, etc are decades old now, gather todays knowledge for a try at starting from the top again. Perhaps a larger aspect is... everyone in the space should probably be thinking about these things. Are these tools and overlays just some ad-hoc complex limited usage highly optimized things for geeks, activists, particular communities, etc? 100k's of users or less with very limited interop capabilities. Or is something larger and more important being built? 500M+'s of users, new RFC's and hardware level everywhere, universal link level full time crypto and padding, are there even such things being designed. How to fit a picture with or evolve todays mainstream app and use models. How to get there? Where is there? When? Someone should start a conference, not on what attendee and projects are doing, but maybe on working to discover the meta of where much of the space should be heading, perhaps even together.