[tor-talk] Onioncat and Tor Hidden Services V3

[grarpamp]

On 9/15/19, Bernhard R. Fischer <bf at abenteuerland.at> wrote:
> The article shows, that it is possible to use OnionCat with HSv3,
> although v3 kills the full automatic addressing method.
> For having a full automatic addressing (i.e. association between v3-id
> und IPv6) some kind of lookup mechanism is necessary.

Right. P2P type of applications start to break down
when the host / user count grows beyond the
10 or so that even private user groups are able
to maintain by hand. For user apps and protocols
that need it, currently v3 breaks the cool automatic
1:1 plug and play scalability that v2 offers.

> this
> could theoretically be managed by DNS, this is NOT a solution because of
> the well-known DNS leakage problem

It would need a specific example.
But in general, that class of "problem" is really a user
configuration and usage problem... ie: use a sandbox.

> (and because the private network's
> reverse delegations are not globally registered and would need some
> workaround).

DNS key-value[s] data fields for onioncat/48 could be handled
within the network overlay itself over the ocat IPv6 interface for UDP,
or over v2 / v3 onion in TCP mode, etc.

The real problem with DNS as data fields for onioncat / tor / i2p / cjdns / etc
is that DNS is a centralized hierarchy... see: SOA. So users or
the entire overlay network using it can and will get lookups
censored, remapped, played, shutdown, etc by DNS operators,
sybils, agents, exploits, and failures in the overlay network.

NameCoin and all sorts of other fully distributed protocols
for hacking a key-value[s] lookup do exist. They could easily
be plugged into onioncat and or tor and run within the network
overlay itself.

However yes, if HSdirs can be used, that seems better,
lightweight, simple, and mostly already exists.


> IMO a solution could be a HSv3-HSv2 compatibility system within the HS
> directory let's call it HSv23.
>
> I propose to create HSv23 entries in the HS dir, which are almost the
> same as HSv2 but with an additional field including the HSv3-id and the
> signature is created by the HSv3 key. The index (i.e. the onion-id) of
> the HSv2a entry is an 80 bit truncated HSv3 id.
>
> The lookup then works as follows:
>
> 1. Convert IPv6 to onion-id (80 bit)
> 2. Retreive the HSv23 entry of the HS dir
> 3. Retreive the HSv3 entry
> 4. Check signatures of HSv23 und HSv3 entry
> 5. Connect to HSv3 service

Maybe try expanding this into a post with picture sketches
on the blog. That way people can see how it would operate
and what parts are needed.