relays have a rather distinct signup and fingerprint pattern usually seen for onion attacks. ... a) If you are an .onion operator I'd like to encourage you to switch to onion services version 3 ... so we can start ... b) dropping onion version 2 services eventually.
These are two separate things not necessarily tied together, thus split for clarity as above.
The former a) is up to the onion operator based on their needs. If they have no need for v2, or need v3, they can or should switch to v3, indeed.
The latter b) is a feature that some users and operators in and for onionspace explicitly choose and depend on to support common apps, and thus would definitely not like to see yanked out from under them. Better instead to advertise and update the default onion semantics for [new] users to v3, and continue support and backport doable features to v2 until time below...
Node operators (tor-relays) would continue offering v2 HSDir support module until such time as the reasons for choosing v2 by those above are supported in v3 or vN.
See the threads on this subject on tor-talk, tor-onions, and tickets for more.
[CC for inclusion, move there if not relay specific]
On 27 Dec 2018, at 04:10, grarpamp grarpamp@gmail.com wrote:
relays have a rather distinct signup and fingerprint pattern usually seen for onion attacks. ... a) If you are an .onion operator I'd like to encourage you to switch to onion services version 3 ... so we can start ... b) dropping onion version 2 services eventually.
These are two separate things not necessarily tied together, thus split for clarity as above.
The former a) is up to the onion operator based on their needs. If they have no need for v2, or need v3, they can or should switch to v3, indeed.
The latter b) is a feature that some users and operators in and for onionspace explicitly choose and depend on to support common apps, and thus would definitely not like to see yanked out from under them. Better instead to advertise and update the default onion semantics for [new] users to v3, and continue support and backport doable features to v2 until time below...
Node operators (tor-relays) would continue offering v2 HSDir support module until such time as the reasons for choosing v2 by those above are supported in v3 or vN.
It's not just about feature parity.
Maintaining a reasonable level of security for v2 onion services requires a lot of paid and volunteer time. We need to find bad relays, and block them on directory authorities.
If we spend a lot of time blocking relays, we can't spend that time on improving other areas of the tor network.
v2 onion services also add a significant amount of load to the Tor network. They use older, inefficient crypto, and they are often targeted by scanners.
If we spend a lot of network resources on v2 onion services, then we can't use those resources for more efficient, user-focused traffic.
So there are many engineering tradeoffs here.
Hopefully, we'll have feature parity on v3 very soon. And then apps will migrate from v2 to v3 (or dual-stack).
It's best if we transition slowly, in a planned manner. But we do need to transition in the next few years. Otherwise, we might have to transition quickly due to network or crypto breaks. And that's not a good experience for anyone.
See the threads on this subject on tor-talk, tor-onions, and tickets for more.
[CC for inclusion, move there if not relay specific]
We try not to have conversations across multiple lists, because it's confusing. It's hard to follow threads, the conversations get split up, and the subjects get mangled.
Let's use tor-relays for further discussion.
T
On 01/03/2019 11:06 PM, teor wrote:
<SNIP>
Hopefully, we'll have feature parity on v3 very soon. And then apps will migrate from v2 to v3 (or dual-stack).
It's best if we transition slowly, in a planned manner. But we do need to transition in the next few years. Otherwise, we might have to transition quickly due to network or crypto breaks. And that's not a good experience for anyone.
I get how that's a great plan. However, OnionCat can't work with v3, even with tweaking, because the address space is orders of magnitude greater than the available IPv6 /48. I suppose that one could use a _way_ bigger IPv6 range, but that would necessarily use IPv6 addresses that are actually assigned on the clearnet. And that'd create chaos if someone peered OnionCat to clearnet.
Alternately, one could somehow restrict v3 hostname creation to a subset, equal in size to the v2 address space (and so to the IPv6 /48 address space). But that sounds computationally expensive. And also perhaps quite the vulnerability.
If OnionCat doesn't get fixed or replaced, and Tor drops v2 support, there will be lots of unhappy users. It's already becoming problematic, with all the unpatched v2 bugs. There might even be enough of a userbase to fork Tor. And that won't be good for anyone, either. But perhaps impacts could be mitigated if fork relays worked with the main network.
<SNIP>
Mirimir wrote:
On 01/03/2019 11:06 PM, teor wrote:
<SNIP>
Hopefully, we'll have feature parity on v3 very soon. And then apps will migrate from v2 to v3 (or dual-stack).
It's best if we transition slowly, in a planned manner. But we do need to transition in the next few years. Otherwise, we might have to transition quickly due to network or crypto breaks. And that's not a good experience for anyone.
I get how that's a great plan. However, OnionCat can't work with v3, even with tweaking, because the address space is orders of magnitude greater than the available IPv6 /48. I suppose that one could use a _way_ bigger IPv6 range, but that would necessarily use IPv6 addresses that are actually assigned on the clearnet. And that'd create chaos if someone peered OnionCat to clearnet.
Alternately, one could somehow restrict v3 hostname creation to a subset, equal in size to the v2 address space (and so to the IPv6 /48 address space). But that sounds computationally expensive. And also perhaps quite the vulnerability.
If OnionCat doesn't get fixed or replaced, and Tor drops v2 support, there will be lots of unhappy users. It's already becoming problematic, with all the unpatched v2 bugs. There might even be enough of a userbase to fork Tor. And that won't be good for anyone, either. But perhaps impacts could be mitigated if fork relays worked with the main network.
That's a good point. Nobody can question the usefulness of OnionCat.
But it eventually needs to be rewritten or patched to support Tor's v3 address format. Because v2 is becoming more and more problematic, its crypto is under current recommendations for security software like Tor, and it also causes more load on the network than v3.
Nobody is even thinking of dropping v2 support _very very soon_, but what if OnionCat never gets replaced? There are many tools out there that are unmaintained but still heavily used, but they can't stale back the development, roadmap and planned improvements over Tor protocol level.
As for the unhappy users, I totally agree we should make them as less unhappy as possible, but think about what teor said: what you think will make them more unhappy:
a) v2 to drop one day suddenly, under some mean and loud CVE, with a lot of pain and disaster recovery plans;
b) gradually and slow but not too slow deprecate v2 in a planned manner and further push the third party tools developers to adapt to v3 for significant benefits and most important of all, their own security so the migration is not sudden and less painful.
Decisions could sometimes be ... in software development especially related to security tools, if you don't keep up with developments and recommended industry standards, well, nobody will risk their own security to wait until you catch-up.
On 01/04/2019 09:17 AM, s7r wrote:
Mirimir wrote:
On 01/03/2019 11:06 PM, teor wrote:
<SNIP>
Hopefully, we'll have feature parity on v3 very soon. And then apps will migrate from v2 to v3 (or dual-stack).
It's best if we transition slowly, in a planned manner. But we do need to transition in the next few years. Otherwise, we might have to transition quickly due to network or crypto breaks. And that's not a good experience for anyone.
I get how that's a great plan. However, OnionCat can't work with v3, even with tweaking, because the address space is orders of magnitude greater than the available IPv6 /48. I suppose that one could use a _way_ bigger IPv6 range, but that would necessarily use IPv6 addresses that are actually assigned on the clearnet. And that'd create chaos if someone peered OnionCat to clearnet.
Alternately, one could somehow restrict v3 hostname creation to a subset, equal in size to the v2 address space (and so to the IPv6 /48 address space). But that sounds computationally expensive. And also perhaps quite the vulnerability.
If OnionCat doesn't get fixed or replaced, and Tor drops v2 support, there will be lots of unhappy users. It's already becoming problematic, with all the unpatched v2 bugs. There might even be enough of a userbase to fork Tor. And that won't be good for anyone, either. But perhaps impacts could be mitigated if fork relays worked with the main network.
That's a good point. Nobody can question the usefulness of OnionCat.
But it eventually needs to be rewritten or patched to support Tor's v3 address format. Because v2 is becoming more and more problematic, its crypto is under current recommendations for security software like Tor, and it also causes more load on the network than v3.
Nobody is even thinking of dropping v2 support _very very soon_, but what if OnionCat never gets replaced? There are many tools out there that are unmaintained but still heavily used, but they can't stale back the development, roadmap and planned improvements over Tor protocol level.
As for the unhappy users, I totally agree we should make them as less unhappy as possible, but think about what teor said: what you think will make them more unhappy:
a) v2 to drop one day suddenly, under some mean and loud CVE, with a lot of pain and disaster recovery plans;
b) gradually and slow but not too slow deprecate v2 in a planned manner and further push the third party tools developers to adapt to v3 for significant benefits and most important of all, their own security so the migration is not sudden and less painful.
Decisions could sometimes be ... in software development especially related to security tools, if you don't keep up with developments and recommended industry standards, well, nobody will risk their own security to wait until you catch-up.
Yes, those are all great points. But I've heard nothing about actual work on OnionCat. Maybe I'm just not connected enough. And maybe it's just that the initial OnionCat developers have moved on. And no one with the right skills has stepped up.
But I do suspect that the fundamental issue is the incomparability of address spaces. Once there's a workable plan for that, it's just coding.
On 1/4/19, V <various> wrote:
"crypto" "security" "sofware dev" "support" fud re v2
"Hey, here's v2, it uses older crypto and mechanics that are not as robust etc as v3... However v2 offers useful features for many users, and those features are not yet available in a newer design (volunteers to create some designs welcomed). As such, v2 received a last and final major formal update, and a backport from v3 concepts, was crafted into a more maintainable modular form, and has now been set out for community maintenance (maintainers welcomed). v3 has been set as default. Users will need to explicitly configure older versions as needed. Volunteer relay operators offer v2 HSDir flag to support users. Here is a table that fully compares and contrasts v2 vs v3 so that users may choose which best suits their needs... And here are roadmaps for v3 and vN ..."
"Please remember before going for a walk... you could trip up your own laces, your shoes could fall apart, you could be mugged, it could even rain, thus walk at your own risk, or stay inside, or just have fun."
This isn't hard, everyone happy.
On 1/4/19, teor teor@riseup.net wrote:
Node operators (tor-relays) would continue offering v2 HSDir support module until such time as the reasons for choosing v2 by those above are supported in v3 or vN.
It's not just about feature parity.
Right. Feature parity is nice and excellent goal, till then, and with *no* plan for same on horizon table, it's about outright removal and killing of long standing features instead of rightly letting users choose from among all features to suit their needs.
Killing ".<node>.exit" in URI's raised some questions, and using MAPADDRESS was the nearly functionally equivalent alternative existing / provided. All good.
Killing v2... whose 80-bit addressing just so happens to enable appending to an RFC4193 /48 to create a 128-bit IPv6 space allocation with its inherent UDP all provided by way of Onioncat and OnionVPN over v2 onions and v2 HSDir nodes... would rip out accessibility to ***entire classes of transport protocols*** that users, and their applications, around the world, need to function properly, and can and do use.
With the main arguments revolving that users are too stupid to select which of v2 or v3 best suits their needs, that v2's benefits have no acceptable tradeoffs for them, etc.
That argument should be rejected.
As should others...
Maintaining a reasonable level of security for v2 onion services requires a lot of paid and volunteer time. We need to find bad relays, and block them on directory authorities.
Not really.
v2 onion in it's current form has been more or less coded, done and operational for ~20 years, minus occaisional bug and enhancement phases.
People have already explained in recent threads how, after the default out of the box mode for all *new* users is changed to v3 onions, those with need to use v2 onions can and will happily explicitly choose v2 and it's tradeoffs, manually in configs, to support their needs. Those tradeoffs should be documented onsite and in v2 man sections.
Tor could even make some future release flag, complain about, and not load any current v2 config it detecs, directing them to such handholding docs until they specify "V2YesMommyImABigKidNow=true".
As far as money goes, the Tor Project takes in $4.2 Million a year. Some of it's people are taking over $178k a piece, with at least 7 of them receiving over $100k, and the true volunteers eschewing all. Those numbers don't include all the slush, side and decentral funding either.
Where's the 210 coders and others receiving $10k stipends for half the budget? Where's the open budget and mechanism? People do inquire this from time to time.
People can start another Subject to comparatively analyse Tor Project alongside other opensource network overlays and cryptographic comms projects, and even other opensource projects in general.
Even start Subjects where other projects could include, remove, or improve on whatever strategy Tor did to reach $4.2M.
There's no lack of funds in Tor Project.
If we spend a lot of time blocking relays, we can't spend that time on improving other areas of the tor network.
Let's define this "blocking" as being of v2 HSDir scraping, not of all the other forms of bad relays. Community volunteers run the public opensource automated scrape detection and reporting tools. The weekly config change volunteer DA's execute based on that is trivial effort. With a bit of logic it's even automateable.
Yet as above, v2 users do and will soon *explicitly* choose and accept those tradeoffs. So that's a non argument too.
v2 onion services also add a significant amount of load to the Tor network. They use older, inefficient crypto, and they are
No. v2 is not some new network tax that just came alone, it's the first mass version and the entire base of onionland. Load is a ratio. v2 used to carry 100% of the load since then, and still carries over 90%. Some crypto is HW accel, some not, in both v2 and v3. And if that was a metric'd and studied issue, even other 80-bit algos could be chosen in some long term v2 support release.
often targeted by scanners.
No again. Let's define what "scanners" might mean... Land of v2 and v3 are equally web spidered 24x365, it's HTML, no one can stop that. Known v3 onions are portscanned just as much as v2 onions are. If "scanning" means "searching for key collisions by generating offline", both v2 and v3 are reasonably collision proof to make that nearly moot. And "scanners" testing generated key lists for HSDir resolve or TCP connect on the live network will learn in one day that there is absolutely zero hope there. So that's all moot.
For separate topic of v2 HSDir "scraping" see above.
If we spend a lot of network resources on v2 onion services, then we can't use those resources for more efficient, user-focused traffic.
No. Users have reasons to use, and do and will continue to select and use v2, even if they have to fork tor. v2 is "used" by "users" and is thus "user-focused" traffic by definition.
So there are many engineering tradeoffs here.
Where?
Draw up a list of what needs to be done to make 80-bit v2 support and engineering better. Work to minimize the diffs between v2 and v3, update whatever algos and protocols in v2 needs addressed, modularize and make v2 pluggable (and vN for that matter), call for extended maintainers, etc.
Hopefully, we'll have feature parity on v3 very soon. And then apps will migrate from v2 to v3 (or dual-stack).
IPv6 (with inherent UDP) parity for v3 onions (or vN) would be awesome :-) There have even been a good number of threads over time where people have suggested ideas on ways to make that happen. Look them up and start from there.
However parity is not there yet, so no such apps and users that need to use v2 for it will migrate there, until then. They will continue to select and use v2 as appropriate.
It's best if we transition slowly, in a planned manner. But we do need to transition in the next few years. Otherwise, we might have to transition quickly due to network or crypto breaks. And that's not a good experience for anyone.
If's already been decided to make v3 the new default. And certainly not unreasonable to make v2 require explict new config to utilize, the placing of a flag to satiate those benevolents having such concerns for users.
However killing v2 is not really a good option until something comes along that provides equivalent of 128-bit IPv6 onion transport (inherently brings UDP), which is today offered by 80-bit v2 onions HSDir and Onioncat.
We try not to have conversations across multiple lists, because it's confusing. It's hard to follow threads, the conversations get split up, and the subjects get mangled.
Inclusion, informing and information is important.
Don't create confusion by bloating and destroying valuable Subject header space with stupid list tags, colossal mistake there made by so many admins and instead of teaching requestors why it's bad.
Use a good MUA that does proper email threading. Trim superfluous entries from To and Cc. Don't top post, don't block quote, don't send HTML, etc...
Put at least some work into all your comms all the time, that way any occaisional missed or overridden elements have minimal effect on the ongoing aggregate sum. Don't be a lazy September fuck.
Let's use tor-relays for further discussion.
Draft a proposal for what aspects might go where.
Maybe tor-relays for v2 HSDir support and their CPU specific bits of the subject.
Yet the overall topic and conversation is much larger. Until it gets figured out, sorted into whatever workbins, what goes where... some inclusion and crossing now and then is in fact efficient, useful, and won't blow up the world :)
tor-relays@lists.torproject.org
-
grarpamp -
Mirimir -
s7r -
teor