[tor-talk] Tor VoIP PBX Architecture Discussion / Onioncat

[grarpamp <grarpamp@xxxxxxxxx>]

> Tor Metrics has some data on average latencies for client to Onion
> service. This is your absolute minimum latency, with the only way to
> reduce this being to have latency-aware path selection

Apps like VoIP, IRC, shell could all benefit from that selection.
Tor doesn't proffer path selection for valid reasons, so probably
won't anytime soon. Third parties might be able to develop
a controller plugin scheme for it, including as a byproduct,
even more metrics that one might wish to also choose nodes
based upon, trust, etc.

> https://metrics.torproject.org/onionperf-latencies.html

These data might generated from already cached HS descriptors,
so initiating a call to uncached would take somewhat longer.
Typically under 2s init, which is fine for any use case.

> Configuring your onion service to not be location hidden would
> improve this.

See the config options to reduce the hop count
in the path controlled by the onion service side.
The client chooses their own side.

> It would be interesting to see what kind of overheads are added by
> OnionCat

Not much.

> but I see that Onioncat is a project that has an end in sight

That's arbitrary.

Alternatively users can say, and Tor can listen... "Onioncat provides
good feature capabilities not provided by anything else, we're using
this, it works for us, or it's a nice feature capability that others can
use, we're aware of tradeoffs, we've evaluated our usage, needs,
and threat models, therefore support for it needs to continue, at
least until a replacement arrives".

That's fair.

> IPv6 addresses are not long enough to encode keys into to make
> them self-authenticating.

Referring explicitly to v3 HS desc... and without truncation,
generation, registration, mapping or other schemes... sure.

However, no... IPv6 address width is long enough for use cases where
it is long enough and not long enough for other use cases where
it is not.

Different use cases might select different strengths based on needs.

Bittorrent users don't need lifetime / PQC level authentication
between peers, they just need enough to prevent nuisance
collisions from degrading operations. Today even the less
than 32 bits of IPv4 (reality: users don't typically brute the ISPs)
are working just fine for that, and the 80 bits over Onioncat will
be sufficient for that for forseeable future. Where they need many
more equivalent bits of strength is likely in encryption, integrity,
and anonymity, not authentication.

Voice and video talkers also might not need lifetime / PQC
resistant authentication when they have additional bits
available to them through hearing and seeing and the
context of the conversation ratchet with their peer[s].
And they can repeat for integrity. But they might want
strong encryption and anonymity. Same for IRC.

Yes, strive to deploy the longest lengths and best accepted
algorithms universally wherever possible, just keep in mind
use cases exist that are quite happy to move all the sliders
around in order to meet their own overall needs.


> IPv6 addresses

Yes, one cannot rationally overload all 128 bits for that without colliding
upon allocated IPv6 space that may appear in one's host stack.
However the 1:1 key network can be larger than 80 bit. One could
easily play with up to say 125 bits by squatting on entirely
unallocated space. (Unlike the clear mistake CJDNS made by
squatting on space already allocated for a specific and conflicting
real world in stack purpose.) Obviously the common library widths
of 96 and 112 could be keyed. And request could be made for a
formal allocation if compatibility and compliance was felt needed
by some mental gymnastics.

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml


> Either we need IPv7

256 bit equivalent strength for all keys and algos including PQC,
represented into addressing... ok, push it through the IETF just
like .onion was.

While you're at it, don't forget to push both...
1) PFS per link encryption, with PQC option
2) chaff fill to the full link rate
... in all switch and router and MAC PHY hardware,
automatically on by default, on every interface, out of the box.

Add to that pushing #OpenFabs and #OpenHW , etc
so that you know what you're getting.

> unless someone comes up with a way to make it work
> with v3 Onion Services.

> perhaps some Onion-native network layer or something else.

Lots of options and ideas here have been and can be
further solicited researched and developed. Search
the lists for Onioncat to find some of them, or generate
your own.

People would like IPv6 and UDP (even raw IP) transport because
their host stacks support it, the internet is moving to it,
many applications simply don't speak .onion or torify poorly,
and it's an interesting capability to plug into other things.

Whether in Tor or some other existing or new network,
try getting together to develop it, or white papering why it
cannot be done in any network ever. Whichever outcome,
any good research there would be a useful addition
to the set other projects might reference in developing
their own work.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk