- tor-dev - lists.torproject.org

Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension
by David Goulet 20 Jun '19

20 Jun '19

9 19

Shortcomings of the pluggable transports specification?
by Philipp Winter 20 Jun '19

20 Jun '19

We are working on improving Tor's pluggable transports specification: <https://spec.torproject.org/pt-spec> The goal is to make the spec useful to more people and fix issues that have accumulated over the years. For more context, have a look at the following ticket, which we use to coordinate this effort: <https://bugs.torproject.org/29285> Before changing the spec, we need to understand its shortcomings and what issues implementers have run into. For those of you who have experience with the spec -- either Tor's version 1.0 or version 2.1 maintained by pluggabletransports.info -- please let us know: * What version of the PT specification and what library implementation (if any) are you using? * What has your experience been with the PT specification? * How would you improve the specification? Thanks, Philipp

3 2

User Data Exchange with Network Automata (re: Prop 305, ex energy)
by grarpamp 17 Jun '19

17 Jun '19

> And this is really off topic for this list. General Tor energy bits moved here... https://lists.torproject.org/pipermail/tor-talk/2019-June/045256.html re 305 etc It wouldn't be unusual for an app to pop up some form of captcha, challenge, or data exchange where needed. Some of that model exists in form of onion service authentication config... some helper data that grants access, makes things happen, whether passive or active interrupt. The controller would be the interface. Yet tor currently has no mechanism on platforms to handle such protocols and popups... thus like onion auth, the user has know they need it for something and configure it in advance. Try investigating an ssh-agent like tor tool... preloaded with users Proof-of-*, 2FA, consumables, etc to dole out, even automatically, where needed and permitted.

1 0

Cryptocurrency: Total Energy Analysis - Crypto Uses Less Than Fiat
by grarpamp 17 Jun '19

17 Jun '19

(from tor-dev: PoW DoS defenses Prop 305: INTRO Cell) On 6/16/19, Chelsea Holland Komlo <me(a)chelseakomlo.com> wrote: > Given the significant environmental impact of POW in other distributed > systems (blockchain), we should not implement schemes that solve a > problem for Tor but create problems for people elsewhere (potentially > irreversible environmental damage). > > https://www.theguardian.com/technology/2018/nov/05/energy-cost-of-mining-bi… One must first understand and enumerate the *entirety of all global energy inputs* going into and making up the legacy fiat currency banking systems, from both Government and Corporate sectors, and its results, before attempting to make any claims that cryptocurrency is "worse" [1]. Such cataloging and analysis requires more work, more data, more actual redpill thought, than just simple hashrate/J/$... so of course people take shortcuts in such articles, as do other people in their pronouncements stemming from them. > Other less-destructive schemes exist to prevent DoS attacks. POW is a > method, not a goal in itself. Taking a step back and examining the full > spectrum of available tools would be better. The needs and model for overlay nets, ie tor, will of course be different than those above. And always interesting where tech various ends up being applied. [1] Hint: Cryptocurrency actually consumes less, and further finally forces inefficiency and other undesired things out of Fiat by displacing it... hopefully faster than it can adapt. Some say that has a value, one that many will be quite happy to sink a bit of premium into if need be.

2 1

OTRv4 summit at PETS2019
by Sofia Celi 17 Jun '19

17 Jun '19

Hi, Tor people! My name is Sofía and I'm the person leading the OTRv4 initiative. I don't know if this is the best place to send this, so if it is not, let me know ;) As part of the work on creating the version 4 of the OTR (Off-the-Record) messaging protocol, we are running a summit in Stockholm, Sweden, the 15 of July, in the morning. This summit runs in parallel with the Privacy Enhancing Technology Symposium 2019 (PETS2019, https://petsymposium.org/2019/index.php) It will be a summit around the work done in the field of secure messaging, deniability and privacy on July 15 on the morning (that is, the day before the start of PETS 2019). It will be held at the Royal Institute of Technology (KTH). You can find it on the official PETS2019 programm: https://petsymposium.org/2019/program.php and on the official otr website: http://otr.im/ The OTRv4 summit will feature a mix of a discussions, short talks and presentations which aim to highlight the importance of privacy, security and deniability in a secure messaging setting to researchers, students, activists and developers. The final schedule for the event will be announced closer to the event. The workshop will start at 9 am and end at 12.30 pm. As one of our developers and my current partner, Ola Bini, has been detained in Ecuador with no actual evidence, we will also talk about this. You can read about this in the latest EFF statement: https://www.eff.org/deeplinks/2019/06/eff-ohchr-iachr-cybercrime-law-interc… We will like that you join us there... so let us know if you can! Thank you! The OTRv4 team -- Sofía Celi @claucece Cryptographic research and implementation at CAD: https://autonomia.digital/ EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F

2 2

Proposal 304: Extending SOCKS5 Onion Service Error Codes
by David Goulet 06 Jun '19

06 Jun '19

3 2

Dealing with critical sbws tickets
by teor 05 Jun '19

05 Jun '19

Hi juga, I read your meeting notes from this week's network team meeting: juga(offline): Week of 05/20 (planned) - Add Tor version to the bandwidth file (#30196) Week of 05/20 (actual) Week of 06/03 (plan) - Continue with #30406: Refactor header constants in sbws to use Stem's one For the next few weeks, can you focus on fixing critical sbws bugs, and helping with authority deployments? Here's what I think we could do: I would like us to deploy sbws to 3/6 bandwidth authorities some time in June. We can do this deployment as soon as another directory authority operator is ready. To deploy more than 3 sbws instances, we need to fix these critical sbws bugs: We need sbws to generate bandwidth lines for all relays with results, even if they are not Running in the sbws tor client's current consensus. https://trac.torproject.org/projects/tor/ticket/29710#comment:13 We need sbws to use MaxAdvertisedBandwidth from the latest descriptors: https://trac.torproject.org/projects/tor/ticket/30733 We also need to look for any more critical bugs in sbws. Here are some ways we can check for bugs: We need to check if all sbws instances exclude some relays, to help us find any more bugs in sbws: https://trac.torproject.org/projects/tor/ticket/30735 90% of sbws measurement attempts fail. But these are internal errors, not network errors. So it looks like sbws has a relay selection bug: https://trac.torproject.org/projects/tor/ticket/30719#comment:2 After we do these tasks, we can deploy sbws to 4 bandwidth authorities. What do you think? T

2 2

Raising AuthDirMaxServersPerAddr to 4?
by Roger Dingledine 04 Jun '19

04 Jun '19

Hi folks, I've been talking to a longtime exit relay operator, who is in the odd position of having a good 1gbit network connection, but only one IP address. He used to push an average of 500mbit on his exit relay, but then the HSDir DoS flatlined his relay for a while (!), and now, perhaps due to the bwauth variability, his exit relay only recovered to maybe 200mbit. He is running a second exit relay on that IP address, but also perhaps due to the bwauth variability, it hasn't attracted much attention either. The real answer is to fix the bandwidth measurement infrastructure. But while we're patiently waiting for progress there, I've been thinking to raise moria1's AuthDirMaxServersPerAddr to 4, i.e. to allow 4 relays per IP address onto the network. I don't think it would significantly increase our risk due to Sybil attacks, whereas there is a clear benefit in terms of some more 100's of mbits of good exit relay capacity. I will propose this change to the dir-auth list in a bit, but here is your chance to point out surprising impacts that I haven't thought of. Thanks! --Roger

3 14

Release: obfs4proxy-0.0.10
by Yawning Angel 02 Jun '19

02 Jun '19

Hello, I just tagged obfs4proxy-0.0.10. The primary changes are a minor fix to the meek_lite behavior when using `utls` as the TLS implementation, and a series of updates (primarily following upstream) to the `utls` library. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.1… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.1… Changes in version 0.0.10 - 2019-04-12: - Disable behavior distinctive to crypto/tls when using utls. - Bump the version of the utls fork. Regards, -- Yawning Angel

5 6

Should we allow matrix.org users on tor IRC channels?
by teor 01 Jun '19

01 Jun '19

Hi all, JeremyRand has asked us to allow matrix.org users on the tor IRC channels on irc.oftc.net. matrix.org users are rejected at the moment, because they are not registered with OFTC. For details, see: https://trac.torproject.org/projects/tor/ticket/30717 T -- teor ----------------------------------------------------------------------

1 0