``` 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.
Instead, we describe here a phased plan to replace TAP in v2 onion services with ntor. This change improves the forward secrecy of _some_ of the session keys used with v2 onion services, but does not improve their authentication, which is strongly tied to truncated SHA1 hashes of RSA1024 keys.
Implementing this change is more complex than similar changes elsewhere in the Tor protocol, since we do not want clients or services to leak whether they have support for this proposal, until support is widespread enough that revealing it is no longer a privacy risk.
## Ntor keys, link specifiers, and SNIPs in v2 descriptors.
We define these entries that may appear in v2 onion service descriptors, once per introduction point.
"identity-ed25519" "ntor-onion-key"
[at most once each per intro point.]
These values are in the same format as and follow the same rules as their equivalents in router descriptors.
"link-specifiers"
[at most once per introduction point]
This value is the same as the link specifiers in a v3 onion service descriptor, and follows the same rules.
Services should not include any of these fields unless a new network parameter, "hsv2-intro-updated" is set to 1. Clients should not parse these fields or use them unless "hsv2-use-intro-updated" is set to 1.
We define a new field that can be used for hsv2 descriptors with walking onions:
"snip" [at most once]
This value is the same as the snip field introduced to a v3 onion service descriptor by proposal (XXX) and follows the same rules.
Services should not include this field unless a new network parameter, "hsv2-intro-snip" is set to 1. Clients should not parse this field or use it unless the parameter "hsv2-use-intro-snip" is set to 1.
Additionally, relays SHOULD omit the following legacy intro point parameters when a new network parameter, "hsv2-intro-legacy" is set to 0: "ip-address", "onion-port", and "onion-key". Clients should treat them as optional when "hsv2-tolerate-no-legacy" is set to 1.
## INTRODUCE cells, RENDEZVOUS cells, and ntor.
We allow clients to specify the rendezvous point's ntor key in the INTRODUCE2 cell instead of the TAP key. To do this, the client simply sets KLEN to 32, and includes the ntor key for the relay.
Clients should only use ntor keys in this way if the network parameter "hsv2-client-rend-ntor" is set to 1, and if the entry "allow-rend-ntor" is present in the onion service descriptor.
Services should only advertise "allow-rend-ntor" in this way if the network parameter "hsv2-service-rend-ntor" is set to 1.
## Migration steps
First, we implement all of the above, but set it to be disabled by default. We use torrc fields to selectively enable them for testing purposes, to make sure they work.
Once all non-LTS versions of Tor without support for this proposal are obsolete, we can safely enable "hsv2-client-rend-ntor", "hsv2-service-rend-ntor", "hsv2-intro-updated", and "hsv2-use-intro-updated".
Once all non-LTS versions of Tor without support for walking onions are obsolete, we can safely enable "hsv2-intro-snip", "hsv2-use-intro-snip", and "hsv2-tolerate-no-legacy".
Once all non-LTS versions of Tor without support for _both_ of the above implementations are finally obsolete, we can finally set "hsv2-intro-legacy" to 0.
## Future work
There is a final TAP-like protocol used for v2 hidden services: the client uses RSA1024 and DH1024 to send information about the rendezvous point and to start negotiating the session key to be used for end-to-end encryption.
In theory we could get a benefit to forward secrecy by using ntor instead of TAP here, but we would get not corresponding benefit for authentication, since authentication is still ultimately tied to HSv2's scary RSA1024-plus-truncated-SHA1 combination.
Given that, it might be just as good to allow the client to insert a curve25519 key in place of their DH1024 key, and use that for the DH handshake instead. That would be a separate proposal, though: this proposal is enough to allow all relays to drop TAP support.
On Mon, May 11, 2020 at 04:47:53PM -0400, Nick Mathewson wrote:
## INTRODUCE cells, RENDEZVOUS cells, and ntor.
We allow clients to specify the rendezvous point's ntor key in the INTRODUCE2 cell instead of the TAP key. To do this, the client simply sets KLEN to 32, and includes the ntor key for the relay.
Clients should only use ntor keys in this way if the network parameter "hsv2-client-rend-ntor" is set to 1, and if the entry "allow-rend-ntor" is present in the onion service descriptor.
Services should only advertise "allow-rend-ntor" in this way if the network parameter "hsv2-service-rend-ntor" is set to 1.
It should be stronger, right? A service that does not advertise allow-rend-ntor (because hsv2-service-rend-tor is unset) MUST reject an ntor key, even if the service actually does support it? Otherwise a client could simply try it even if support is not advertised?
On Mon, May 11, 2020 at 5:58 PM Ian Goldberg iang@uwaterloo.ca wrote:
On Mon, May 11, 2020 at 04:47:53PM -0400, Nick Mathewson wrote:
## INTRODUCE cells, RENDEZVOUS cells, and ntor.
We allow clients to specify the rendezvous point's ntor key in the INTRODUCE2 cell instead of the TAP key. To do this, the client simply sets KLEN to 32, and includes the ntor key for the relay.
Clients should only use ntor keys in this way if the network parameter "hsv2-client-rend-ntor" is set to 1, and if the entry "allow-rend-ntor" is present in the onion service descriptor.
Services should only advertise "allow-rend-ntor" in this way if the network parameter "hsv2-service-rend-ntor" is set to 1.
It should be stronger, right? A service that does not advertise allow-rend-ntor (because hsv2-service-rend-tor is unset) MUST reject an ntor key, even if the service actually does support it? Otherwise a client could simply try it even if support is not advertised?
Ah yes, you're right.
Hi Nick,
On 12 May 2020, at 06:48, Nick Mathewson nickm@torproject.org wrote:
## Migration steps
First, we implement all of the above, but set it to be disabled by default. We use torrc fields to selectively enable them for testing purposes, to make sure they work.
Can you expand on the testing plan here?
One of the risks with multi-year migration projects is that unrelated changes break the migration, and we don't notice.
For example, you might need to create a chutney network for each stage, and run them on every pull request and merge. In our current CI, that's 30-60 seconds of extra time per network, or 2-4 extra minutes of CI time.
If you need to test different combinations of features for each stage, let's try to do that in the same networks. Otherwise, the testing matrix expands out very quickly.
T
On Mon, May 11, 2020 at 8:52 PM teor teor@riseup.net wrote:
Hi Nick,
On 12 May 2020, at 06:48, Nick Mathewson nickm@torproject.org wrote:
## Migration steps
First, we implement all of the above, but set it to be disabled by default. We use torrc fields to selectively enable them for testing purposes, to make sure they work.
Can you expand on the testing plan here?
One of the risks with multi-year migration projects is that unrelated changes break the migration, and we don't notice.
For example, you might need to create a chutney network for each stage, and run them on every pull request and merge. In our current CI, that's 30-60 seconds of extra time per network, or 2-4 extra minutes of CI time.
If you need to test different combinations of features for each stage, let's try to do that in the same networks. Otherwise, the testing matrix expands out very quickly.
I agree here think that the right approach here is to test for the various ways that we expect the network to exist at a time. The trickiest stage of the migration will be the one where some services support ntor keys and some don't, some clients do and some don't. If we add a chutney network for that case specifically and make sure that all clients can reach all services, we should be fine here.
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.
Cheers! David
Hi Nick,
On 14 May 2020, at 00:09, David Goulet dgoulet@torproject.org 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?
T
On Thu, May 14, 2020 at 12:46:42AM +1000, teor wrote:
Hi Nick,
On 14 May 2020, at 00:09, David Goulet dgoulet@torproject.org 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
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?
Hi there,
On 19. May 2020, at 19:55, Nick Mathewson nickm@torproject.org wrote: 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.)
I would be exstatic about not having V2 onions around anymore. This would reduce a huge attack vector that incentivizes people to set up malicious relays, which causes huge amounts of time lost, the relays shouldn't have this opportunity to harvest onions, etc.
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.) .
I kind of don't buy the statement in the parentheses, we don't seem to discourage v2 strongly at all afaict. Or is there a warning when you use it or connect to it, for example?
A question, is the HSDir flag for both v2 and v3 onions? If not we could just take that away to break v2 at some point.
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.
I think it should have been started a while ago :)
What do others think?
Cheers Sebastian
On 19 May (13:55:37), Nick Mathewson wrote:
On Wed, May 13, 2020 at 10:09 AM David Goulet dgoulet@torproject.org wrote:
On 11 May (16:47:53), Nick Mathewson wrote:
[snip]
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.
[snip]
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.) .
I don't believe at any point since v3 is stable we made public statement through our TPO channels that v2 should not be used anymore.
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 easy timeline here would be "No v2 support in walking onions means deprecation for v2 by the time the entire network updates".
But apart from that, yes we should work on a timeline and it should not be a complicated one nor eternally long to deploy.
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.
Honestly, I really don't think we should even provide or mention a possible path with an option where v2 can stay alive...
Regardless of threat modelling or v2 use cases or large community of users, the basic fact that the crypto is *dangerously* out of date with RSA1024 and truncated SHA-1 is just something we have to _stop_ using. I see this not only about TAP.
I'll say it and say it again and again, today, in 2020, v2 is _dangerous_ and it is our responsibility at this point to make sure it goes away sooner than later for the safety of Tor's users.
Cheers! David
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.
-
David Goulet -
Ian Goldberg -
Nick Mathewson -
Nick Mathewson -
Paul Syverson -
s7r -
Sebastian Hahn -
teor