On Wed, May 13, 2020 at 10:09 AM David Goulet dgoulet@torproject.org wrote:
On 11 May (16:47:53), Nick Mathewson wrote:
Hello!
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 haven't read the entire proposal so I won't comment on its technical aspect. I was reading and got here and that made me very uncertain about the whole proposal itself.
I will propose that we revisit the overall idea of changing v2 here.
I personally think this is the wrong approach. Onion services v2 should be deprecated as in removed from the network instead of being offered as a choice to the users.
We haven't properly done a deprecation path yet for v2 primarly due to our lack of time to do so. But at this point in time, where the network is 100% composed of relays supporting v3 now (which took 3+ years to get there), it is time for v2 to not be presented as a choice anymore.
It is a codebase that is barely maintained, no new features are being added to it and thus moving it to ntor means another at least 3 years of network migration. This would mean a major new feature in that deprecated code base...
So thus, I personally will argue that moving v2 to ntor is really not the right thing to do. Onion service v2 are, at this point in time, _dangerous_ choice for the users.
Hi, David! I'm sympathetic to this point of view: I certainly don't like carrying around old code either.
If we do decide to finally deprecate v2 onion services, that would be a significant maintenance burden reduced for us, but we'd have to handle the transition carefully. Unlike all the other migrations we've done, there isn't a drop-in path to get the same functionality or keep the same identities with v3 onion services. (And the problem is that there _can't_ be: the identities are strongly tied to 80-bit-truncated-SHA1 and RSA-1024, and the lack of key blinding makes them enumerable.)
The main reason I wrote this proposal is this: Any deprecation will probably cause a few users to stick with the old versions of the code for as long as they still work on the network, even if those versions become unsupported and insecure. (After all, people who listen to our advice about what is secure and what isn't have already stopped using v2 onion services.) .
Is it time to start this deprecation? If so we need to start working on a timeline, and I agree with Teor that we'd need to figure out how that timeline would work with any walking onions timeline.
One possible role for this proposal is to be kept in reserve, in case somebody feels so strongly that they want v2 services to work that they want to maintain them themselves, or pay for somebody else to do it. If so, we can indicate this proposal as "the right way to keep v2 services working without TAP", make it clear that we don't plan to implement it, and move along.
There are other ways to keep TAP working with walking onions, but they seem kludgey too, and would also require implementation changes for v2 onion services.
What do others think?