Nick Mathewson wrote:
Filename: 320-tap-out-again.md Title: Removing TAP usage from v2 onion services Author: Nick Mathewson Created: 11 May 2020 Status: Open(This proposal is part of the Walking Onions spec project. It updates proposal 245.)
# Removing TAP from v2 onion services
As we implement walking onions, we're faced with a problem: what to do with TAP keys? They are bulky and insecure, and not used for anything besides v2 onion services. Keeping them in SNIPs would consume bandwidth, and keeping them indirectly would consume complexity. It would be nicer to remove TAP keys entirely.
But although v2 onion services are obsolescent and their cryptographic parameters are disturbing, we do not want to drop support for them as part of the Walking Onions migration. If we did so, then we would force some users to choose between Walking Onions and v2 onion services, which we do not want to do.
I also think this might not be worth it. The engineering time-cost far exceeds the gains and it also decreases the security of users with yet another penalty on Tor network performance and code-base maintenance. It just extends the time of inevitable: dropping v2 onions entirely, so I agree with Teor, David and Paul.
I won't also repeat the obvious about RSA1024 and SHA1, these two just don't mix up well with Tor and the attention it gets, the userbase it has and the amount of motivated, well funded attackers particularly targeting onion services.
What I can say and could make a penny here is that I really keep an eye on onion services usage in external, unrelated projects, and keep contact with people in those communities. To be frank, I think that at present time most of v2 onion traffic is from bitcoin full nodes in Tor-land, facebook and people using onioncat for UDP in Tor or other tunneling related stuff.
They do so not because they want or like, but simply because v3 onion addresses are much larger and need some code change. However, work is undergo. IIRC onioncat was already patched to support v3 at some level. Bitcoin is changing their p2p protocol to support larger address space.
Other v2 onion traffic might be our own apt repositories channels and other tp.o services, as well as some Debian derivatives offering updates over Tor -- these all know about v3 onion services and want to move to v3 -- they were just waiting for OnionBalance v3 which I heavily tested and it was improved (asn's credit - I only did the testing and bug hunting): at this moment there is a tagged 0.2.0 release which is rock solid and can safely be used in PROD mode.
Of course there is probably an unknown number of websites that still use v2, but I am pretty sure they will switch to v3 sooner rather than later. After all, it's trivial to switch for most users (those that don't have dependencies on tools that do not support such large addresses - I'm not aware of any others than what I've mentioned).
All in all I can only see advantages in adding enhancements and improvements to v3 onion services and setting a reasonable and smooth deprecation plan for v2 services. The crypto used in v2 is already under recommendations - while of course it doesn't technically mean that if Tor supports them it also endorses them, some users might still not get it and don't upgrade to v3 unless they really need to (on the logic as long as it works, leave it on). Forcing the upgrade for users own protection + a lot of benefits on Tor network and code side mentioned by teor does not seam like a wrong approach at all to me.
Thanks.