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

[grarpamp]

On 1/24/19, Alec Muffett <alec.muffett at gmail.com> wrote:
> On Thu, 24 Jan 2019 at 19:33, grarpamp <grarpamp at gmail.com> 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.