[tor-dev] Proposal 320: Removing TAP usage from v2 onion services

[s7r]

 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20200513/fee3cbe1/attachment.sig>