Re: [tor-relays] Onion v2 HSDir Support (ref: v3 prop224) [was: fishy fingerprint patterns]

[Mirimir <mirimir@xxxxxxxxxx>]

On 01/04/2019 09:17 AM, s7r wrote:
> Mirimir wrote:
>> On 01/03/2019 11:06 PM, teor wrote:
>>
>> <SNIP>
>>
>>> Hopefully, we'll have feature parity on v3 very soon. And then
>>> apps will migrate from v2 to v3 (or dual-stack).
>>>
>>> It's best if we transition slowly, in a planned manner. But we do
>>> need to transition in the next few years. Otherwise, we might have
>>> to transition quickly due to network or crypto breaks. And that's
>>> not a good experience for anyone.
>>
>> I get how that's a great plan. However, OnionCat can't work with v3,
>> even with tweaking, because the address space is orders of magnitude
>> greater than the available IPv6 /48. I suppose that one could use a
>> _way_ bigger IPv6 range, but that would necessarily use IPv6 addresses
>> that are actually assigned on the clearnet. And that'd create chaos if
>> someone peered OnionCat to clearnet.
>>
>> Alternately, one could somehow restrict v3 hostname creation to a
>> subset, equal in size to the v2 address space (and so to the IPv6 /48
>> address space). But that sounds computationally expensive. And also
>> perhaps quite the vulnerability.
>>
>> If OnionCat doesn't get fixed or replaced, and Tor drops v2 support,
>> there will be lots of unhappy users. It's already becoming problematic,
>> with all the unpatched v2 bugs. There might even be enough of a userbase
>> to fork Tor. And that won't be good for anyone, either. But perhaps
>> impacts could be mitigated if fork relays worked with the main network.
>>
> 
> That's a good point. Nobody can question the usefulness of OnionCat.
> 
> But it eventually needs to be rewritten or patched to support Tor's v3
> address format. Because v2 is becoming more and more problematic, its
> crypto is under current recommendations for security software like Tor,
> and it also causes more load on the network than v3.
> 
> Nobody is even thinking of dropping v2 support _very very soon_, but
> what if OnionCat never gets replaced? There are many tools out there
> that are unmaintained but still heavily used, but they can't stale back
> the development, roadmap and planned improvements over Tor protocol level.
> 
> As for the unhappy users, I totally agree we should make them as less
> unhappy as possible, but think about what teor said: what you think will
> make them more unhappy:
> 
> a) v2 to drop one day suddenly, under some mean and loud CVE, with a lot
> of pain and disaster recovery plans;
> 
> b) gradually and slow but not too slow deprecate v2 in a planned manner
> and further push the third party tools developers to adapt to v3 for
> significant benefits and most important of all, their own security so
> the migration is not sudden and less painful.
> 
> Decisions could sometimes be ... in software development especially
> related to security tools, if you don't keep up with developments and
> recommended industry standards, well, nobody will risk their own
> security to wait until you catch-up.

Yes, those are all great points. But I've heard nothing about actual
work on OnionCat. Maybe I'm just not connected enough. And maybe it's
just that the initial OnionCat developers have moved on. And no one with
the right skills has stepped up.

But I do suspect that the fundamental issue is the incomparability of
address spaces. Once there's a workable plan for that, it's just coding.
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays