On 9/24/13, Bernhard R. Fischer bf@abenteuerland.at wrote:
On Thursday 19 September 2013 10:53:13 grarpamp wrote:
On 9/13/13, George Kadianakis desnacked@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.