Re: [tor-relays] Onion v2 HSDir Support (ref: v3 prop224) [was: fishy fingerprint patterns]

[grarpamp <grarpamp@xxxxxxxxx>]

On 1/4/19, teor <teor@xxxxxxxxxx> 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 mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays