October 2021 - tor-dev - lists.torproject.org

Arti report 7: September 30 through October 13
by Nick Mathewson 14 Oct '21

14 Oct '21

# Arti Report 7: September 30 through October 13 ## Guards are working! Finally, at long last, we've got Guard nodes working in Arti! When we first made our roadmap, we set our first milestone as "Arti has all the features necessary for basic anonymity." Now that Guards are implemented, all of those features are done! Does this mean that Arti is now production-ready for anonymous use? No, not yet. Just because we no longer have _missing_ privacy features doesn't mean that those privacy features are actually implemented correctly. We'll need a lot more testing, debugging, and experimentation. Also, it's very possible we've forgotten something. We'll need careful auditing to be sure. ### Interesting guard issues There are more issues to fix and features to add to the guard implementation down the road. For a current list, have a look at [this comment](https://gitlab.torproject.org/tpo/core/arti/-/issues/58#note_27549…, which lists them. ## What's next Over the next couple of weeks, we'll be working on smaller issues, bugfixes, and miscellaneous cleanups for an upcoming "0.0.1" release, targeting November 1. You can see our latest progress [here]((https://gitlab.torproject.org/tpo/core/arti/-/milestones/6). ## Thanks! Thanks to Jani Monoses for progress towards a WASM port, and Trinity Pointard for updates to dependencies.

1 0

IANA well-known URI suffix registration for tor-relay-fingerprints file
by nusenu 10 Oct '21

10 Oct '21

Hi, to reduce the risk of certain kinds of attacks I'm aiming to submit a short spec (like [1]) in accordance with RFC8615 https://tools.ietf.org/html/rfc8615#section-3.1 for the registration of of a suffix for the verifyurl from https://github.com/nusenu/ContactInfo-Information-Sharing-Specification#ver… The name I have in mind is: tor-relay-fingerprints The file contains comments (lines starting with #) and relay fingerprints. https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml Let me know if you have any feedback on this and whether you have any opinion on whether you (The Torproject) wants to be the change controller. The only question that came up was: Will there be two types of relay fingerprints in the future (Ed25519)? thanks, nusenu -- https://mastodon.social/@nusenu [1] https://keybase.io/docs/keybase_well_known

5 22

tor Prometheus Metrics Documentation
by nusenu 10 Oct '21

10 Oct '21

Hi, since Neel is working on unix socket support [1] for MetricsPort I'm preparing to add support for it to relayor. I don't like to add additional attack surface to a relay but since tor does not support TLS and basic auth on the MetricsPort I'll likely install nginx that takes care of TLS and authentication. If you have any opinion on that I'd also like to hear it. It would be nice to have a documentation for all tor prometheus metrics in the man page or on a website, some information can be found at [3] but not all. Is there already a complete documentation for tor prometheus metrics data? Here is an example of how other projects have documented their metrics [5]. I don't know if it is too late for that but it would be great to use the well known IANA RCODE [4] naming for the DNS return codes where possible instead of the custom naming. examples (just guessing): tor_relay_exit_dns_error_total{... reason="format"} -> FormErr? tor_relay_exit_dns_error_total{... reason="notexist"} -> NXDomain? kind regards, nusenu [1] https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/453 [3] https://support.torproject.org/relay-operators/relay-bridge-overloaded/ [4] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-pa… [5] https://doc.powerdns.com/recursor/metrics.html#metricnames related feature request: [2] https://gitlab.torproject.org/tpo/core/tor/-/issues/40194 -- https://nusenu.github.io

1 0

ed25519_master_id_public_key -> ed25519 id
by nusenu 10 Oct '21

10 Oct '21

Hi, given a relay's ed25519_master_id_public_key file, is there a simple way to generate the 43 chars long ed25519 identity string (also found in fingerprint-ed25519)? thanks, nusenu -- https://nusenu.github.io

2 3

Re: [tor-dev] Proposal 335: An authority-only design for MiddleOnly
by ezhigp＠Safe-mail.net 08 Oct '21

08 Oct '21

> ``` > Filename: 335-middle-only-redux.md > Title: An authority-only design for MiddleOnly > Author: Nick Mathewson > Created: 2021-10-08 > Status: Open > ... > > These flags SHOULD be set in a vote whenever `MiddleOnly` is > present, and only when the authority is configured to vote on the > `BadExit` flag. > > * `BadExit` > > These flags SHOULD be cleared in a vote whenever `MiddleOnly` is > present. > > * `Exit` I believe that BadExit is supposed to be given together with Exit, to mark that technically it's possible to exit from this relay, but it is not recommended unless you know what you do. > * `Guard` > * `HSDir` > * `V2Dir` It looks like we don't fear such a relay at Intro? Or it is a sign that this proposal is only a set of quick actions before #334?

1 0

v2 Onions, IPv6 BiDir P2P Capability Regression... [re: Relays running unsupported EOL ver]
by grarpamp 07 Oct '21

07 Oct '21

On that, and regardless of what TPO Inc says re... tor is a bit decentralized, and freely licensed, as such... DirAuths, HSDirs, Relays are all free to choose to continue signing over and running older versions in order to support the community of tor clients that are happily using useful features that the Tor Project on its high horse demands with its blanket fiat fist and refusing to consider and support users... to remove from such users, herein as noted before, v2 onions and simple OnionCat IPv6 /48+80 UDP transport P2P E2E BiDir addressing and thus all current IPv6 capable apps incl VOIP Bittorrent comms status chat game coins etc and future apps that needing such tech to operate across onionland. That's bad, and a big regression in service, both active now, and preventing potential development on interesting new uses and applications in the future. These users, these features, apps, and their recognized tradeoffs, their free choices made therein, are of merit and import. And Tor Project is choosing to censor and ban v2 and them without regard. Perhaps some v2 users will likewise email all the relays seeking not their censorship, but instead their support. But perhaps due to any needs they may have to remain unknown they may not be able to voice out to lists etc, as such the surfaceweb cannot make dis-use assumptions and must indeed hold v2 in their stead for them. Kudos to those distributed DirAuths, HSDirs, and Relays who refuse to comply with Tor Project Inc demands to crush all v2 onion users and their legitimate use cases. The better path is for TPO to either recognize and continue, or to modularize v2 onion support out to community stewardship such that the features that it provides may continue until a future vN or a seamless scalable externally attached solution for the same features and uses is found. And to make v3 the default choice "advertised" in docs and configs, with v2 a lesser noted option yet for just providing above capabilities. Tor Project still doesn't have a version feature matrix table, nor an honest open balanced and free to all authors wiki education page detailing use case and tradeoff notes for users about the v2+OnionCat vs v3 tech capabilities, thereby allowing tor users to freely make educated choices therein on their own. Instead it has a bricked up and censored prop blog and lists. Like TPO's censorship, that's unfair, unwarranted, questionable, and needs to end. ps: Yes, upgrade, if merely behind on versions sake, lots of good fixes, improvements, performance, features, security, etc come with those. But when it comes to a big and permanent regression of overall network capability issue such as this, that's different, and needs consideration beyond the vague handwavy universal whitewash "reason" being uttered by TPO such as "v2 insecure"... which is false re educated tradeoffs and uses that users are free to evaluate and choose on their own. In fact, users are in better more intelligent aware position having learned a bit of something and made that themselves. Users are also free to eval by bring forward to today sense of the NSA's 10+ year old slides that noted "Tor Stinks". What conditions, designs, capabilities, etc have changed since then. Cheers all. On 10/5/21, Georg Koppen <gk(a)torproject.org> wrote: > Relays running unsupported Tor versions is a problem we have never > really dealt with in a systematic way in the way. Some of you might > recall that we (with the help of volunteers) tried back in 2019/2020 to > get operators, running an unsupported Tor version, to upgrade[1] but > then we dropped the ball. Alas. > > We just started that process again by contacting every relay operator > running an outdated Tor version (any version not 0.3.5.x or 0.4.5.x or > 0.4.6.x or 0.4.7.x) by email where possible. Additionally, we created a > wiki page outlining the current process and things we still need to > figure out.[2] On that page we plan to make statistics related to the > EOL relay removal available as well, including the final list of relays > we'll reject. Thus, stay tuned. Feedback, as always, is very much welcome! > > We plan to keep this topic on our radar this time while refining the > process as we go. Meanwhile, if you are running a relay with an > unsupported Tor version, please upgrade for the sake of our users' safety. > > If you need help, join us on #tor-relays or #tor-relays:matrix.org if > you use Element. > > [1] https://blog.torproject.org/removing-end-life-relays-network > [2] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Relay-EOL-pol…

1 0

Updated Proposal 324: RTT-based Congestion Control for Tor
by Mike Perry 06 Oct '21

06 Oct '21

As a heads up, I have updated Proposal 324: RTT-based Congestion Control for Tor - https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/324-rt… The updated version has a new congestion control algorithm, detailed specifics on how to accurately measure RTT and BDP, and descriptions of algorithm parameter values and tuning experiments, among other improvements. A C implementation of these algorithms has been merged to tor.git orgin/main. They live in src/core/or/congestion_control_*.[ch]. These algorithms are not enabled yet; we still need to implement flow control and negotiation, as well as do shadow experimentation to determine good candidate parameter values to further tune on live. Here is a full changelog since the proposal was last published to tor-dev: - Correct algorithms to update once per congestion window - Add orconn blocking and edge connection checks as signals - Specify BDP estimators based on onion service testing and eval. - Specify a pure BDP tracking congestion control algorithm (TOR_NOLA) - Update consensus parameters with tuning notes - Document what we learned so far in live onion service experimentation - Mention that we need to test intermittent downloads in Shadow/live - Describe clock jump and stall detection during RTT measurement - Mention if we calculate package window, it can become negative - Break off the backwards ECN idea into a future idea draft: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/ideas/… - Update old trac URLs - Add Acknowledgements Review and comments are welcome! -- Mike Perry

1 1

(Short) Arti Report 6: September 15 through September 30
by Nick Mathewson 01 Oct '21

01 Oct '21

# Arti Report 6: September 15 through September 30 ## Activities since our last report Hello! Lots of code since last time, but not so much to say about it. I'm chugging ahead on the Guard nodes implementation, but it isn't done yet. Most of the code is there, but I need to write tests, chase down a few spec issues, fix a couple of things that "don't feel right", and integrate it all with tor-circmgr. You can track progress on the guard implementation at <https://gitlab.torproject.org/tpo/core/arti/-/issues/58>. ## Thanks! Thanks to Jani Monoses for refactoring, Daniel Eades for cleanup, and Trinity Pointard for OSX reproducible builds and integration testing (!).

1 0