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

[Nick Mathewson <nickm@xxxxxxxxxxxxxx>]

On Wed, May 13, 2020 at 10:09 AM David Goulet <dgoulet@xxxxxxxxxxxxxx> 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?

-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev