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

[Paul Syverson <paul.syverson@xxxxxxxxxxxx>]

On Thu, May 14, 2020 at 12:46:42AM +1000, teor wrote:
> Hi Nick,
> 
> > On 14 May 2020, at 00:09, David Goulet <dgoulet@xxxxxxxxxxxxxx> wrote:
> > 
> > On 11 May (16:47:53), 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 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.
> 
> I agree that we shouldn't support old features forever. And it seems unwise
> to spend development effort just to migrate away from TAP, when we could
> instead spend that time migrating away from TAP and v2 onion services.
> (And reducing our dependency on SHA1 and RSA keys.)
> 
> Strategically, it also seems unwise to carry v2 onion services, TAP
> handshakes, RSA relay keys and signatures, and SHA1 into walking onions.
> 
> But it's hard to make these kinds of decisions without approximate
> timeframes.
> 
> How long would it take to migrate away from v2 onion services?
> 
> How long would it take to introduce walking onions?
> 
> If we decide to modify v2 onion services, how long would that migration
> take? And what's the final plan to end the modified v2 onion services?
> 

I completely agree about not maintaining things forever and that there
are security reasons for abandoning v2 (much) sooner than later, but
as always I don't think we can just blanketly state what is a
dangerous choice for users without specifying a usage and adversary
context. I'm not trying to open a discussion of how dangerous this is
or getting people to give that specification, only cautioning against
such unqualified statements.

Another element in this decision making is whether to take into
account and engage with the userbase for v2 onion services. The most
salient case is probably facebook, but there may be others with a
significant amount vested in specific v2 addresses. We could just make
decisions about a timeline and inform them, or we could engage with at
least some of the more popular or larger v2 onion services to see if
they have reasons e.g. why officially announcing EOL in e.g. 3 months
is fine, but 2 months would make for craziness for them.

Si Vales, Valeo,
Paul
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev