- tor-dev - lists.torproject.org

Bandwidth scanner: request for feedback
by teor 20 Nov '18

20 Nov '18

Hi, Juga and pastly have been working hard on sbws. Sbws' results are now similar to torflow's results: https://trac.torproject.org/projects/tor/attachment/ticket/27135/20180826_0… Now that sbws is close to torflow, we want some feedback on its design. We’ll work on the design at the tor meeting in September. Please feel free to give feedback by email, or on the tickets: What happens when sbws doesn't match torflow? https://trac.torproject.org/projects/tor/ticket/27339 We suggest this rule: If an sbws deployment is within X% of an existing bandwidth authority, sbws is ok. (The total consensus weights of the existing bandwidth authorities are within 25% - 50% of each other, see #25459.) How long should sbws keep relay bandwidths? https://trac.torproject.org/projects/tor/ticket/27338 Torflow uses the latest self-reported relay observed bandwidth and bandwidth rate. Torflow uses a complex feedback loop for measured bandwidths. We think sbws can use a simple average or exponentially decaying weighted average. How should we scale sbws consensus weights? https://trac.torproject.org/projects/tor/ticket/27340 If sbws' total consensus weight is different to torflow's total consensus weight, how should we scale sbws? (The weights might differ because the measurement method is different, or because scanners and servers are in different locations.) In the bandwidth file spec, we suggest linear scaling. How should we round sbws consensus weights? https://trac.torproject.org/projects/tor/ticket/27337 Torflow currently rounds to 3 significant figures (which is a maximum of 0.5%). But I suggest 2 significant figures for sbws (or max 5%), because: - tor has a daily usage cycle that varies by 10% - 20% - existing bandwidth authorities vary by 25% - 50% Proposal 276 contains a slightly more complicated rounding algorithm, which we may want to implement in sbws or in tor: https://gitweb.torproject.org/torspec.git/tree/proposals/276-lower-bw-granu… Does sbws need a maximum consensus weight fraction? https://trac.torproject.org/projects/tor/ticket/27336 Torflow uses 5%, but I suggest 1%, because the largest relay right now is only 0.5%. T -- teor Please reply @torproject.org New subkeys 1 July 2018 PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ----------------------------------------------------------------------

4 4

How does Tor plan to deal with HTTP/3 (HTTP over QUIC)
by neel＠neelc.org 17 Nov '18

17 Nov '18

Hi @tor-dev mailing list, How would Tor deal with HTTP/3 (a.k.a. HTTP over QUIC), considering that Tor is a TCP anonymizer, and HTTP over QUIC (and QUIC itseld) uses UDP? Would we need Tor to support UDP? Just QUIC? Thanks, Neel Chauhan === https://www.neelc.org/

2 1

Empty menu item in Help menu
by scootergrisen 12 Nov '18

12 Nov '18

I tried testing Tor Browser in macOS (VirtualBox) and at the bottom of the Help menu i see a empty menu item. If i remember correct nothing happened if i clicked it.

2 1

Icon misaligned in macOS drag icon dialog
by scootergrisen 12 Nov '18

12 Nov '18

The icon is misaligned in macOS for the installer or whatever it is called.

2 1

network team weekly meeting - nov 12th
by Gaba 12 Nov '18

12 Nov '18

Hi! This week's network team meeting is on Monday at 1800 UTC. Our meetings are held on #tor-meeting on OFTC. cheers, gaba

1 0

A few wtf-pad/prop254 questions
by Nick Mathewson 07 Nov '18

07 Nov '18

Hi! I'm looking over prop254 and I have a few questions or clarification requests that I hope will make things clearer to me. Some of these are probably "wrong questions" that stem from a misunderstanding of the underlying proposal. 1) What does "ito" stand for? Is it documented? 2) How is RTT measurement meant to work? It seems to me from reading section 3.1 that middle if a middle node sees a delay of N ms between getting a cell in the forward direction, and getting a cell in the backward direction, then it will conclude that the RTT is at least N ms. But that doesn't make sense to me -- the latter cell might have been sent in response to a different cell, or sent asynchonously, and not in response to the first cell at all. AFAICT unless we can be reasonably sure that we are seeing a packet that is sent in response to an earlier cell, be sure that we're actually measuring min(rtt). Maybe some pseudocode would help me understand better. 3) In section 3.1, I'm assuming that "cell sent" and "cell received" refer to a cell that we are originating, and a cell that we are receiving, recognizing, and processing: relayed cells don't count. Is that correct? 4) I like that section 3.1.1 specified delays in terms of microseconds, but we should be aware that with current implementation restrictions, microsecond-level precision is unlikely to actually be realistic. I hope that's okay. 5) In section 3.1.1, can we include a formula for the bounds of the n'th bin? 6) In section 3.1.1, why is a uniform distribution used, and not some other distribution? 7) In section 3.1 (I'm not sure where) can we specify how bins are initialized, and how they are refilled (if at all)? 8) For machine negotiation (in section 3.3), I'd suggest that we have the client send a list of acceptable machines in preference order, rather than demanding a particular machine. I think a 16-bit identifier is safer than an 8-bit one. We should reserve an area of the identifier space for experimental use. 9) Can we include an example definition of one of these state machines, with pseudocode included? 10) Should clients (eventually) begin killing circuits if they receive padding from an unexpected place? cheers, -- Nick

3 2

Proposal 298: Putting family lines in canonical form
by Nick Mathewson 31 Oct '18

31 Oct '18

Filename: 298-canonical-families.txt Title: Putting family lines in canonical form Author: Nick Mathewson Created: 31-Oct-2018 Status: Open Target: 0.3.6.x 1. Introduction With ticket #27359, we begin encoding microdescriptor families in memory in a reference-counted form, so that if 10 relays all list the same family, their family only needs to be stored once. For large families, this has the potential to save a lot of RAM -- but only if the families are the same across those relays. Right now, family lines are often encoded in different ways, and placed into consensuses and microdescriptor lines in whatever format the relay reported. This proposal describes an algorithm that authorities should use while voting to place families into a canonical format. This algorithm is forward-compatible, so that new family line formats can be supported in the future. 2. The canonicalizing algorithm To make a the family listed in a router descriptor canonical: For all entries of the form $hexid=name or $hexid~name, remove the =name or ~name portion. Remove all entries of the form $hexid, where hexid is not 40 hexadecimal characters long. If an entry is a valid nickname, put it into lower case. If an entry is a valid $hexid, put it into upper case. If there are any entries, add a single $hexid entry for the relay in question, so that it is a member of its own family. Sort all entries in lexical order. Remove duplicate entries. Note that if an entry is not of the form "nickname", "$hexid", "$hexid=nickname" or "$hexid~nickname", then it will be unchanged: this is what makes the algorithm forward-compatible. 3. When to apply this algorithm We allocate a new consensus method number. When building a consensus using this method or later, before encoding a family entry into a microdescriptor, the authorities should apply the algorithm above. Relay MAY apply this algorithm to their own families before publishing them. Unlike authorities, relays SHOULD warn about unrecognized family items.

1 0

Updates and review on "Proposal 254: Padding Negotiation"
by George Kadianakis 30 Oct '18

30 Oct '18

Hey Mike, I took another look at prop#254 and made some changes of my own in my torspec branch circuitpadding-proposal-updates (see commit ab37543). Let me know if they look right to you. Some of those I had to look into the code to understand, and I hope I got them right. Furthermore, I opened a pull request with a few questions and comments for further improvements and clarifications: https://github.com/torproject/torspec/pull/39 Cheers!

1 0

Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
by Piyush Kumar Sharma 29 Oct '18

29 Oct '18

Hello all, I have a few specific questions related to the pluggable transports. 1.) I believe that obfs4 stops active probing(the latest problem as brought to notice by Ensafi et al, IMC 2015 and Shinying Cho, FOCI 2018), and hence discovering obfs4 Tor bridges using active probing is not possible. Is that true? If so, then we are good to go and hence we don't need any other pluggable transport to work for us as long as obfs4 is working? 2.) What was the motivation to bring in meek as a pluggable transport, given the fact that obfs4 works great to cover all the existing problems with Tor detection. Was the motivation just the fact that, it will be much easier for the users to use meek than obfs4 or something other than this? 3.) I searched a lot but could not find the timeline in which pluggable transports were built. As in what was developed and deployed first, obfs4 or meek? Regards Piyush IIITD

7 6

Add EVENT message to pt-spec.txt and control-spec.txt
by David Goulet 29 Oct '18

29 Oct '18

Greetings tor-dev! We've been working on improving PT reporting towards Tor so for instance Tor Browser can better inform the user or take actions based on the PT state when connecting to the network. The following ticket summarize it: https://trac.torproject.org/projects/tor/ticket/28180 To achieve this, we are submitting these to torspec.git patches to extend both the pt-spec.txt and control-spec.txt to support such mechanism. This is the first draft. Below is the link to the PT spec patch. It adds the EVENT message that for now is only used, as you will see, for reporting connection status message. However, you should see this EVENT message as extendable to whatever the PT would like to report to Tor that we can think of in the future: https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket2818… The second, is simpler, it is how Tor will send it back to the control port: https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket2818… Please, any questions or feedbacks is very welcome! The main idea here is to keep things simple and extendable. Note that since Tor doesn't implement the PT 2.0 spec yet, we haven't done anything for that spec but after skimming the version 2, I think we can easily move this EVENT message concept if we want it. Cheers! David -- t2Mtu4qBote14xSTFee/xnHlXp1eabwHFbehBlktnus=

2 2