[tor-dev] RFC of proposal draft for "Migration to ed25519 HS identity keys and privacy-preserving directory documents"

[Nick Mathewson]

On Thu, Sep 19, 2013 at 4:53 AM, grarpamp <grarpamp at gmail.com> 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.

I have nothing against onioncat, but let's remember that the fact that
you can squeeze a Tor hidden service address into an IPv6 address is
completely accidental.

If we want to keep that ability when hidden service addresses become
longer than 128 bits, the obvious solution would be to add some kind
of translation layer.

yrs,
-- 
Nick