[tor-dev] Onion IPv6 transport needed [was: ed25519 HS identity keys]

[grarpamp]

On 9/24/13, Bernhard R. Fischer <bf at abenteuerland.at> wrote:
> On Thursday 19 September 2013 10:53:13 grarpamp wrote:
>> On 9/13/13, George Kadianakis <desnacked at riseup.net> wrote:
>> > This proposal is in serious need for comments.
>> >
>> > 1.2. From the PoV of the HS client:
>> >   Tor clients can distinguish new-style HS addresses from old ones by
>> >   their length. Legacy addresses are 16 base32 characters, while new
>> >   ones are 56 (XXX) base32 characters.
>> >
>> >   If Tor is asked to connect to a legacy address it SHOULD throw a
>> >   warning and advocate the use of new-style addresses (it should still
>> >   connect to the HS however). In the future, when old-style HS
>> >   addresses are close to depletion, we can introduce a torrc parameter
>> >   that blocks client connections to old-style HS addresses.
>>
>> As commented earlier on this list...
>> https://lists.torproject.org/pipermail/tor-dev/2013-August/005286.html
>>
>> This addressing change will break onioncat (IPv6) within Tor.
>> https://www.onioncat.org/
>>
>> I suggest a solution to transporting IPv6 within Tor be
>> maintained/deployed concurrently with any change in
>> current onion addressing and or transport mechanics.
>
>
> 56 base32 characters means 280 bits.
> And yes, the new addresses will break Onioncat addressing mechanism.
>
> Actually this is the same problem as with I2P which uses 256 bit addresses
> for
> the destinations.
> Then, as a workaround I implemented an /etc/hosts file-based lookup. This is
>
> not a perfect solution but it was better than nothing ;)
>
> I'll think about a new method of addressing, which allows forward
> compatibility (DNS comes into my mind -- I know...)

I know, yet I don't mind the central nature of DNS for naming.
It works on clearnet, you can subscribe to multiple roots to avoid
censure and under an anonymous system someone will always
be willing to carry the sensational records. So you can resolve
just fine. The problem is the transport. Being able to resolve is
pointless if you can't transport. And if you can transport you can
resolve on top of that any which way you want, including DNS.
I'm sure this is not really a naming issue but an addressing
one.

If people expect Tor, I2P etc to ever evolve to support for
real p2p/social apps and services and build communities beyond
what crippling unidirectional TCP is capable of (which I suggest
we should), they need to transport IPv6. And to do that you need
to have nodes fall within private RFC/48 addressing bound to an
interface... whether natively as Tor currently does by byproduct
with onioncat providing the layer, or via some future address
mapping layer [1].

The 'DNS' you speak of could map 80bit to n-greater-than-80bit,
(256/280/512 bit) within an internal backend of a new ocat that
then transports to the higher bits. But if actual DNS was used
for that it would invoke the root/censor/uptime/trust issues of DNS
for *addressing* not naming, and we don't really want that type of
breakdown there. Ocat currently does not have those problems.
And if someone comes up with the likes of [1], a central trust
system like DNS won't be needed.

To the extent this is a wider summary, if there's an IPv6 transport
(mod hidden addressing) ticket where reference to this should
be lodged, please do.

[1] Search for IPv6 on zzz.i2p, there were some comments
found there of possible map considerations like signed
announcements into DHT. Maybe also namecoin-like
addressing.