- tor-dev - lists.torproject.org

Walking onions status update: week 6 notes
by Nick Mathewson 10 Apr '20

10 Apr '20

Walking Onions: week 6 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories, binary diffs, metaformat decisions, and Merkle Tree trickery. https://lists.torproject.org/pipermail/tor-dev/2020-March/014178.html Week 2: Specifying details of SNIP and ENDIVE formats, in CDDL. https://lists.torproject.org/pipermail/tor-dev/2020-March/014181.html Week 3: Expanding ENDIVEs into SNIPs. https://lists.torproject.org/pipermail/tor-dev/2020-March/014194.html Week 4: Voting (part 1) and extending circuits. https://lists.torproject.org/pipermail/tor-dev/2020-March/014207.html Week 5: Voting (part 2) https://lists.torproject.org/pipermail/tor-dev/2020-April/014218.html This week I did a pass through all of the proposal that's written so far, trying to revise it for consistency and to look for unexpected gaps. Then I wrote a first take on a section about client behavior, and outlined sections about how to keep onions services working. == Fixing inconsistencies There were, predictably, some places where I had wrote things in an introduction to a section, and then turn around and did them differently later in the section. I tried to make those consistent when I could. For one example, I think Microdescs should now be embedded in votes. They were separate before, for space reasons, but now that we have defined support for compression and diffs in voting, we don't need to keep votes as small as we did before. But when I went to explain voting, I didn't actually give a place to put in microdescriptors. This is fixed now. == Example rules, and changes to voting. Thanks to Teor's help and feedback on previous iterations of voting, the voting operations [VOTING] are now more consistent, and specified more consistently. I had to describe a "sorting" operation for use with voting, since CBOR's default "canonical" ordering is not what we actually want semantically. To try to make sure voting could do what we need, I wrote up an example VotingRules object in a new appendix [EXRULES]. This turned up a few impedance mismatches between the available voting rules, the SNIP format, and the ENDIVE format. I fixed some of these, and marked others with "XXX" strings to come back and fix on the next pass through voting. == More index and extension protocol work I've found a need for a new link specifier (LS) for use with onion services. Unlike a regular routing index LS, this kind includes a routing index and a count of how many relays to skip after that position. This lets a client say, for example, "Give me the third relay after the one whose HDirIndex is 0xbf9630". (In order to answer this query, the extending relay needs to return not only the SNIP for the third relay, but all SNIPs between the first relay and that relay, so that the client can trust the answer.) This kind of LS can be used with the new NIL handshake if the client _only_ wants to fetch the descriptors; the details are in the circuit-protocol section [EXTENDING]. == Client operations, part 1 In a new section 06, I've sketched out solutions for guards, bridges, bootstrapping, and several kinds of path restriction [CLIENTS]. In doing so I've turned up a possible need for new IP-based and key-based indices; I've added those to a new appendix where I'm listing the different indices I think we'll need [INDEXLIST]. == Outlines of work to come I've added outlines for a new section 7 about making onion services work, and a new section 8 about tracking some new ways that relays might have to misbehave. I've also added quick sketches for a pair of additional proposals we'll need: one for a better family notation, and one for finally migrating away from the last vestiges of TAP. But none of those are quite next: In the coming week, if time permits, I want to get exit policies figured out. They are the biggest missing piece of section 06 right now, and seem to me to be the biggest remaining gap in the specification. == Fun facts: At 109KiB, this is now the longest Tor proposal ever. I will need to come up with a different fun fact next week. == References: [CLIENTS] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/06-clien… [EXTENDING] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/05-exten… [EXRULES] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/AF-examp… [INDEXLIST] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/AG-index… [VOTING] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/03-votin…

1 0

Walking onions status update: week 5 notes
by Nick Mathewson 06 Apr '20

06 Apr '20

Walking Onions: week 5 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories, binary diffs, metaformat decisions, and Merkle Tree trickery. https://lists.torproject.org/pipermail/tor-dev/2020-March/014178.html Week 2: Specifying details of SNIP and ENDIVE formats, in CDDL. https://lists.torproject.org/pipermail/tor-dev/2020-March/014181.html Week 3: Expanding ENDIVEs into SNIPs. https://lists.torproject.org/pipermail/tor-dev/2020-March/014194.html Week 4: Voting (part 1) and extending circuits. https://lists.torproject.org/pipermail/tor-dev/2020-March/014207.html This week found me still rather distracted by fallout from current events and preparations for more isolation at home. I didn't get a complete rewrite done. But I do, however, think I figured out voting. == The big idea for voting Our current system for voting on relay properties is fairly piecemeal: every property has its own independent specification in dir-spec.txt [DIRSPEC], which can get kind of cumbersome. Every time we have a new property to specify, if it can't be defined as a flag, we need to define a new consensus method that puts it in the consensus or the microdescriptors. Until authorities have upgraded to support the new method, they can't sign consensuses generated with it, since they don't know how those consensuses are generated. We can solve both problems by defining "vote tabulation" as a set of parameterized operations operating over a set of CBOR inputs. Individual operations can be simple, like "Take the median of all integer votes", or progressively more complex. What's more, we can specify these voting operations themselves as data, which gives us more advantages: First, that we no longer need independent English-language specs for each field in the consensus--and second, that we can introduce new voting rules or change the existing ones without adding new code. As long as a quorum of authorities agree about the rules for voting on some field, the other authorities can safely follow those rules, and include the new field in the consensus ENDIVE and SNIPs. We would only need to introduce new consensus methods when we wanted to introduce support for an entirely new operation. After voting is done, some transformations are needed to transform the objects it produces. SNIP signatures need to be signed, indexes built, and so on. I've left this unspecified for now, since I am likely to return to the SNIP and ENDIVE formats again in the coming weeks, and I'll want to tweak the transformation quite a lot. This is not something I would want to implement in C. Rust would be a better fit -- or some functional language. Fortunately, only authorities need to follow this algorithm. I have initial specifications written for these operations that I believe are sufficient (or nearly so?) for all the things that we do in voting now. These are in the draft voting spec as it stands [VOTING]. I expect that they are full of errors, but I wouldn't be too concerned right now; I'm going to need to do another pass over them, but I want to return to voting a bit later (see below) once I have more SNIP uses specified. == Backward compatibility in voting There are two separate backward compatibility issues in voting. The first issue is easier: how to operate when we aren't sure whether all the authorities have upgraded to support this new voting format. For this purpose, I'm including legacy votes as part of the new vote format, signatures and all. This will make the new votes bigger until all the authorities have definitely upgraded, but other changes (voting diffs and compression) should offset this risk. We can stop sending legacy votes when everybody has upgraded. (I thought about having an "implicit version" of each legacy vote derived from the new vote, but that seemed riskier, and like it would involve lots more new code of dubious benefit.) The second issue is a bit harder: for clients that haven't upgraded to walking onions, we'll need to generate legacy consensus documents for a some time. This doesn't need to follow exactly the same rules as consensus voting uses today: instead we should have legacy consensus documents derived from the CBOR consensus, so that we only need to maintain one voting algorithm long term. I've left this part unspecified for now too; I'll be comping back to it after a round of revisions and SNIP usage design. == Next steps I plan to spend the first part of week going over what I've written so far and trying to make it correct and consistent, and to fill in the baps that I have. After that, I'm planning to write the example sections for how circuit extension works. If time remains, this is when I finally move on to section 6 of the proposal, which will be pretty involved -- I've got to explain how to implement all (or most?) of our current client behavior using walking onions, and what that implies about the set of indexes and fields in our documents. == Other updates Our paper got into USENIX Security 2020! (This is the paper about Walking Onions that Chelsea Komlo and Ian Goldberg wrote with me. It has basically the same content as our existing tech report [TECHREPORT].) The conference is scheduled in mid-August, in Boston: we'll see whether people are gathering in groups by then. If not, I imagine we'll be putting together some kind of video. [DIRSPEC] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt [TECHREPORT] https://crysp.uwaterloo.ca/software/walkingonions/ [VOTING] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/03-votin…

1 0

Re: [tor-dev] Chutney tests fail for tor/maint-0.3.5 (bug #33677)
by c 01 Apr '20

01 Apr '20

(Forgot to hit "reply all" in my mail client) On Mon, 30 Mar 2020 13:22:21 +1000 teor <teor(a)riseup.net> wrote: > This ticket is a cleanup ticket, after some other changes have been made. > I've edited the ticket description to make that clearer. Understood, thank you for clarifying. > Check for onion service descriptor uploads: > https://trac.torproject.org/projects/tor/ticket/33609 > > Someone else is working on the microdescriptor changes at the moment. > > Would you like to start working on the onion service descriptor changes? Sure, it would give me an opportunity to learn about onion descriptors in more detail. I will get started on it. But first, looking at it more, I think my struggle with understanding what to do stems from my unfamiliarity with the Chutney codebase (first I have heard of the tool was with this project, even though commits date back to 2011). I need to make sure I understand #33609 sufficiently: - Is the requested functionality only for Chutney or will Tor potentially need any changes to allow for HS verification? - So I know where to begin looking in the codebase, the ticket wants us to "check each onion service log" -- is this referring to Tor log output (such as the instances chutney spawns), chutney-specific logs, or something else entirely? - For "check v2 and v3 onion services" -- check if they've propagated the network? - For "call it an extra 200% 'bootstrap' stage" -- again is this chutney-specific? I only know bootstrapping percentage from Tor notice-level logging and obviously it only goes up to 100%, so I'm wondering if "200%" is a magic number here or something arbitrary. From this and the parent #33050 it doesn't seem to me like the request is very clear. I am reading proposals 311-313 after sending this message so maybe I can come across some answers to my questions/confusions via the proposals themselves. The proposals will probably give me a better idea of the work I am in for overall, too, and perhaps I should have come across them sooner. I figure it is wise regardless to ask for clarification here and read while I wait for feedback. Efficiency and all :) Caitlin

2 1

txtorcon 20.0.0
by meejah 01 Apr '20

01 Apr '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm pleased to announce txtorcon 20.0.0. This fixes a few bugs and officially deprecates Python 2 support. * Use real GeoIP database or nothing (https://github.com/meejah/txtorcon/issues/250) * Change abstract base classes import in preperation for Python 3.8 (thanks @glowatsk) * Python 3.4 is no longer supported * Python 2 is deprecated; all new code should be Python 3. Support for Python 2 will be removed in a future release. You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/20.0.0 https://github.com/meejah/txtorcon/releases/tag/v20.0.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-20.0.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-20.0.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 122cd081786396f57718adda1c1a5eb01b8e9a4832fcd140918b45c10359377a txtorcon-20.0.0.tar.gz 5c1145566a8733105da851b794e7b15cb56cea48693635b55c4bddfb79fe629d txtorcon-20.0.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCgAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAl6EDnURHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaadv4AgAkIny/Pt55kEppkxlqu4/B4ddfU7oQNLD 8lwoYyUZbYtS8XwiBaqY6SR/UU9MhhswdoPU50WBq3h4Im+3jrmm7MbVD4uR6Uvt BnZIMzCJlQNcGpfbaGmtyrtbBNazQLTDOAxxQ7WM/MD8rip1zlP8MeL7yBgE3VEC JInw9DWN+fbQhbsTQgdiLLLhBXOFqZuXgz7auPnGzu+5LsIeJd6ZnWzuQ6TlzL3R rLgrMAasxTMzKoJB51jmDpCOeaj4b68XK+MY130/xSdENb2ZyGbuSF4LpZUjs4RU Sqiwtevu/bT/th0XBqcg79RHnwGLK/g1pJRB27RaOVbuh6f+lENc4Q== =4q9v -----END PGP SIGNATURE-----

1 0

Improving onion service availability during DoS using anonymous credentials
by George Kadianakis 30 Mar '20

30 Mar '20

Hello list, there has been lots of discussions about improving onion service availability under DoS conditions. Many approaches have been proposed [OOO] but only a few have been tried and even fewer show any real improvements to the availability of the service. An approach that we've been considering is the use of anonymous credentials as a way to prioritize good clients from bad clients. The idea is that the service gives tokens to clients it believes to be good, and prioritizes client with tokens over clients without tokens whenever possible. This is a post to start a discussion of how such approaches could work and whether they are worth pursuing futher. == Preliminaries == === When should the access control take place? === Doing DoS defenses with anon credentials is all about enforcing access control at the right point of the protocol so that the amplification factor of evil clients gets cut as early as possible. Very roughly the phases of the onion service protocol are: descriptor fetch phase, intro phase, rendezvous phase. Let's see how those look like for the purposes of access control: - Doing the access control during the descriptor fetch stage is something worth considering because it's the first phase of the protocol and hence the earliest and best place to soak up any damage from evil clients. There is already a form of optional access control implemented here called "client authorization" and it's worth thinking of what's lacking to make it useful against DoS attackers. I'm gonna address this in section [CLIENTAUTH]. - Doing the access control during the introduction phase is another fruitful approach. Blocking bad clients during introduction means that they dont get to force the service to create a costly rendezvous circuit, and since services have a long-term circuit open towards the intro points it makes it easier for services to pass access control related data to the intro point. This is actually the approach we are gonna be talking most about in this post. - Finally, doing the access control during the rendezvous phase is way too late since by that time the onion service has already spent lots of resources catering the evil client, so let's ignore that. === Entities of an anonymous credential system === Anonymous credential systems traditionally have three entities that concern us: - The Issuer: the entity who issues the credentials/tokens - The Prover: the entity who collects tokens and uses them to get access - The Verifier: the entity who verifies that tokens are legit and grants/restricts access In the world of onion services, the Issuer is naturally the onion service, and the Prover is the onion service client. The Verifier could either be the onion service itself or its introduction points. We will see below how this could work and the relevant tradeoffs. +--------+ +------------+ +--------------------+ | Client |<-+-+-+-->|Intro point |<--+---+-->|Onion service | |(Prover)| |(Verifier?) | |(Issuer)(Verifier?) | +--------+ +------------+ +--------------------+ === How do tokens get around? === A main question here is "How do good clients end up with tokens?". For the purposes of this post, we will assume that clients get these tokens in an out of band fashion. For example, a journalist can give tokens to her sources over Signal so they can use them with Securedrop. Or a forum operator can give tokens to old-time members of the forum to be used during a DoS. A natural chicken-and-egg problem occurs here since how is an onion service supposed to give tokens to its users if it's unreachable because of a DoS? We realize this is a big problem and we are not sure exactly how to solve it. This problem naturally limits the use of anonymous credential solutions, and sorta makes them a second-layer of defense since it assumes a first-layer of defense that allows operators to pass tokens to the good people. A first-layer approach here could perhaps look like PrivacyPass where users get tokens by solving CAPTCHAs. == Anonymous credentials == By surveying the anonymous credential literature we have found various types of anonymous credential schemes that are relevant for us: - Discrete-logarithm-based credentials based on blind signatures: This is a class of anon credential schemes that allow us to separate the verifier from the issuer. In particular this means that we can have the service issue the tokens, but the introduction point being the verifier. They are usually based on blind signatures like in the case of Microsoft's U-Prove system [UUU]. - Discrete-logarithm-based credentials based on OPRF: Another approach here is to use OPRF constructions based on the discrete logarithm problem to create an anonymous credential scheme like in the case of PrivacyPass [PPP]. The downside, IIUC, is that in PrivacyPass you can't have a different issuer and verifier so it's the onion service that needs to do the token verification restricting the damage soaking potential. - KVAC (Keyed-Verification Anonymous Credentials): KVAC-based credentails have comparable performance to Dlog-based credentials, and are also easier to create security proofs for due to them being based on symmetric primitives like algebraic MAC constructions [FFF]. The downside is that they assume that the verifier and the issuer is the same entity (the onion service). KVACs are used by Signal for protecting their group chat metadata [GGG]. Which construction and scheme we choose depends on our constraints and the parameters we are trying to minmax. So let's try to explore these constraints and parameters some more. == Space constraints == Let's assume that a client found some anonymous credentials for a service. How will clients present their credentials to the verifier, being either the service or the intro point? The natural approach here is for the client to include their token as part of the INTRODUCE1 cell. === How much space is available in INTRODUCE1 cells? [SPACE_CONSTRAINTS] === >From a brief experiment, I see that the INTRODUCE1 cell payload total size is 498 bytes, and we are already using 310 bytes from it, so that leaves about 188 bytes for use. The cell is extensible using cell extensions that can go either to the intro point [III] or to the service directly [EEE]. === How big are anonymous credentials redemptions? === >From looking at the literature it seems unlikely that those anonymous credentials can be presented given the size limitations from above. In particular here is the size needed for presenting/redeeming an anonymous credential in the various schemes: - Privacy Pass [PPP]: Credential redemption takes 396 bytes - Signal [GGG]: Their paper does not say exactly, but by peeking into their code it seems like presenting the credential takes about 620 bytes [CCC]. So if I'm not mistaken, it seems like we will need another way to present anonymous credentials to the service or intro point. === How can we trasmit these credentials then? === The unfortunate fact here is that presenting those credentials does not fit into the remaining space of an INTRODUCE1 cell, but it also wouldn't even fit if we created an entirely new relay cell for this purpose (say INTRO_REDEEM) since the relay cell payload is about 498 bytes and all the credentials above, except from PrivacyPass (!), are bigger than that. This means that we will either need to use a space-compact anonymous credential scheme, or to implement wide relay cells as suggested in ticket #33650 (which seems like lots of work!). == Computational constraints [COMPUTATIONAL_CONSTRAINTS] == Another big topic for consideration here is the computational resources required for the various operations of the scheme. In particular, how hard it is to issue such tokens, present such tokens and to verify such tokens. Different schemes have different computational profiles. I'm not gonna attempt to summarize the literature here because it will take me more time than I have right now. However, it's clear that our main priority here is a lightweight verification procedure, so that services or intro points spend as little energy as possible validating (potentially evil) tokens. It's imperative that verifying tokens is orders of magnitude more lightweight than the regular job that a service would do if credentials did not exist (i.e. doing path selection, creating a rendezvous circuit, doing the crypto, etc.) Our second priority here is a lighweight token issuance procedure, so that services don't spend too much time issuing tokens, especially if this is done in an automatic real-time manner that can be abused by an adversary. And finally, we don't particularly care about the token presentation procedure being lightweight, since this is a procedure that the attacker will also have to do and hence we want to incur as much costs to them as possible. == Discussion == ==== What's lacking from HSv3 client authorization [CLIENTAUTH] ==== It's really important to understand what's lacking from descriptor-level client authorization [QQQ] with regards to DoS defences before we spend time and energy implementing any anonymous credential approach. To use the descriptor-level client authorization feature for DoS protection the onion service operator creates a mirror of the website that is only reachable using descriptor-level client auth and then they pass client auth tokens to the clients they trust to be good natured. The above system can also be automated and turned into a web service. However this system has a bunch of drawbacks: - Given the implicit and anonymous nature of the descriptor-level client authorization system, if an evil actor gets their hand in a client auth token and they start DoSing the service, then the operator has no means to distinguish that client from any other client. Hence there is no way to identify individual bad clients and revoke them. This is the biggest issue with descriptor-based client authorization for the purposes of DoS defense. - Managing the access list (adding and removing clients) in the descriptor-level client authorization system is an expensive process because it requires uploading a new set of descriptors. Doing this too often (in an automated way) can cause lots of network traffic and also perhaps race conditions with clients who fetch descriptors. - Because the authentication happens by adding new lines on the descriptor, there is a fundamental limit on how many authed clients it can support. In particular, with some back-of-the-envelope calculations [ZZZ] an onion service can support a max of 250 authed clients this way. However, there is nothing stopping the operator from passing the same token to multiple clients and managing them as groups. The above issues would be addressed with intro-level client authorization since the authentication is explicit and done in real-time. It's worth thinking of the above drawbacks more and how we can bypass them to do something useful with the current system before we jump into new complexities and tradeoffs. --- Thanks for reading and looking forward to your feedback :) [OOO]: https://trac.torproject.org/projects/tor/ticket/31223 [ZZZ]: https://lists.torproject.org/pipermail/tor-dev/2016-November/011658.html [QQQ]: https://eprint.iacr.org/2013/516.pdf [PPP]: https://www.petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf [UUU]: https://www.microsoft.com/en-us/research/project/u-prove/ [FFF]: https://eprint.iacr.org/2013/516.pdf [GGG]: https://signal.org/blog/signal-private-group-system/ [III]: https://github.com/torproject/torspec/blob/f81b1e6cc53b91abb3ae206807bc371f… [EEE]: https://github.com/torproject/torspec/blob/f81b1e6cc53b91abb3ae206807bc371f… [CCC]: https://github.com/signalapp/zkgroup/blob/4294e428216113d81f5c0cb50f578797d…

2 2

Chutney tests fail for tor/maint-0.3.5 (bug #33677)
by c 30 Mar '20

30 Mar '20

Hi, For the Outreachy.org internship project I decided to take on bug #33677 [1]. I followed steps to run `make test-network-all` both on tor master and maint-0.3.5 branches, using Chutney master branch. I tested before and after tweaking value of HS_WAIT_FOR_UNCHECKED_DIR_INFO just to ensure my testing environment was sane; all tests passed (except for two that were skipped on master: mixed+hs-v23 and mixed+hs-v23-ipv6, and one on 0.3.5: mixed+hs-v2, I assume this is expected though) on the first go, on both branches of Tor. Tests pass on Tor master after setting HS_WAIT_FOR_UNCHECKED_DIR_INFO to 0, but on maint-0.3.5 I've run tests a few times (both with and without CHUTNEY_DEBUG set) each time with a different outcome. Some of the tests which fail: basic-min [2], single-onion-v23 [3], bridges+ipv6-min [4], and ipv6-exit-min [5]. I have excerpted logs at the bottom of this message, narrowed down to test failures; let me know if I need to provide full logs or additional information. I'll keep digging on this issue; I just wanted to show my current progress and share what I hope to be useful information. Caitlin [1]: <https://trac.torproject.org/projects/tor/ticket/33677> "Stop waiting a set time for onion service descriptors" [2]: basic-min.log [...] Connecting: Exit to 127.0.0.1:4747 via client localhost:9005 DEBUG: socket 5 connecting to ('localhost', 9005)... DEBUG: Registering send-data-11 DEBUG: Registering check-12 Transmitting Data: DEBUG: Socks 4a request to 127.0.0.1:4747 DEBUG: Test status: {'send-data-11': 'not done', 'check-12': 'not done'}: 2/0/0 DEBUG: Test status: {'send-data-11': 'not done', 'check-12': 'not done'}: 2/0/0 DEBUG: Done with run(); all_done == False and failure_count == 0 Transmission: Failure [...] chutney verify round 1/1 failed Chutney failed 1 bootstraps; we may have a problem here. FAIL basic-min (exit status: 1) [3]: single-onion-v23.log [...] Connecting: HS to bkjqakom5elyh45a.onion:5858 (127.0.0.1:4747) via client localhost:9005 DEBUG: socket 7 connecting to ('localhost', 9005)... DEBUG: Registering send-data-21 DEBUG: Registering check-22 HS to moymkdharroenjd6zarfurdwmrr55j2zune6k7wafyfakwy2cis327id.onion:5858 (127.0.0.1:4747) via client localhost:9005 DEBUG: socket 8 connecting to ('localhost', 9005)... DEBUG: Registering send-data-23 DEBUG: Registering check-24 Transmitting Data: DEBUG: Socks 4a request to bkjqakom5elyh45a.onion:5858 DEBUG: Socks 4a request to moymkdharroenjd6zarfurdwmrr55j2zune6k7wafyfakwy2cis327id.onion:5858 DEBUG: new client from 127.0.0.1:54314 (fd=9) DEBUG: successfully connected (fd=8) DEBUG: Succeeded send-data-23 DEBUG: successful verification DEBUG: Succeeded check-24 DEBUG: Test status: {'send-data-21': 'not done', 'check-22': 'not done', 'send-data-23': 'success', 'check-24': 'success'}: 2/2/0 DEBUG: Test status: {'send-data-21': 'not done', 'check-22': 'not done', 'send-data-23': 'success', 'check-24': 'success'}: 2/2/0 DEBUG: Done with run(); all_done == False and failure_count == 0 Transmission: Failure [...] chutney verify round 1/1 failed Chutney failed 1 bootstraps; we may have a problem here. FAIL single-onion-v23 (exit status: 1) [4]: bridges+ipv6-min.log [...] Couldn't launch test005bc command '/home/c/git/tor/src/app/tor -f /home/c/git/chutney/net/nodes/005bc/torrc': exit 1, output 'Mar 28 10:47:36.717 [notice] Tor 0.3.5.10-dev (git-38e07b88fac51f2a) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.7. Mar 28 10:47:36.717 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Mar 28 10:47:36.717 [notice] Read configuration file "/home/c/git/chutney/net/nodes/005bc/torrc". Mar 28 10:47:36.721 [warn] You have used DirAuthority or AlternateDirAuthority to specify alternate directory authorities in your configuration. This is potentially dangerous: it can make you look different from all other Tor users, and hurt your anonymity. Even if you've specified the same authorities as Tor uses by default, the defaults could change in the future. Be sure you know what you're doing. Mar 28 10:47:36.721 [warn] TestingTorNetwork is set. This will make your node almost unusable in the public Tor network, and is therefore only advised if you are building a testing Tor network! Mar 28 10:47:36.722 [notice] Opening Socks listener on 127.0.0.1:9005 Mar 28 10:47:36.722 [warn] Could not bind to 127.0.0.1:9005: Address already in use. Is Tor already running? Mar 28 10:47:36.722 [notice] Opening Control listener on 127.0.0.1:8005 Mar 28 10:47:36.722 [warn] Could not bind to 127.0.0.1:8005: Address already in use. Is Tor already running? Mar 28 10:47:36.722 [notice] Opening Control listener on /home/c/git/chutney/net/nodes/005bc/control Mar 28 10:47:36.722 [notice] Opened Control listener on /home/c/git/chutney/net/nodes/005bc/control Mar 28 10:47:36.722 [notice] Closing partially-constructed Control listener on /home/c/git/chutney/net/nodes/005bc/control:0 Mar 28 10:47:36.722 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. Mar 28 10:47:36.722 [err] Reading config failed--see warnings above. ' [...] Launching chutney using Python 3.7.6 DEBUG: Tor version 0.3.5.10-dev (git-38e07b88fac51f2a). test000a is running with PID 2870: Tor 0.3.5.10-dev (git-38e07b88fac51f2a) test001a is running with PID 2873: Tor 0.3.5.10-dev (git-38e07b88fac51f2a) test002ba is running with PID 2911: Tor 0.3.5.10-dev (git-38e07b88fac51f2a) test003r is running with PID 2879: Tor 0.3.5.10-dev (git-38e07b88fac51f2a) test004br is running with PID 2882: Tor 0.3.5.10-dev (git-38e07b88fac51f2a) test005bc is stopped: Tor 0.3.5.10-dev (git-38e07b88fac51f2a) 5/6 nodes are running [...] bootstrap-network.sh failed Chutney failed 1 bootstraps; we may have a problem here. FAIL bridges+ipv6-min (exit status: 1) [5]: ipv6-exit-min.log [...] Connecting: Exit to 127.0.0.1:4747 via client localhost:9005 DEBUG: socket 5 connecting to ('localhost', 9005)... DEBUG: Registering send-data-11 DEBUG: Registering check-12 Transmitting Data: DEBUG: Socks 4a request to 127.0.0.1:4747 DEBUG: Test status: {'send-data-11': 'not done', 'check-12': 'not done'}: 2/0/0 DEBUG: Test status: {'send-data-11': 'not done', 'check-12': 'not done'}: 2/0/0 DEBUG: Done with run(); all_done == False and failure_count == 0 Transmission: Failure [...] chutney verify round 1/1 failed Chutney failed 1 bootstraps; we may have a problem here. FAIL ipv6-exit-min (exit status: 1)

2 1

Walking onions status update: week 3 notes
by Nick Mathewson 30 Mar '20

30 Mar '20

Walking Onions: week 3 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories, binary diffs, metaformat decisions, and Merkle Tree trickery. https://lists.torproject.org/pipermail/tor-dev/2020-March/014178.html Week 2: Specifying details of SNIP and ENDIVE formats, in CDDL. https://lists.torproject.org/pipermail/tor-dev/2020-March/014181.html You might like to check out those updates, and their references, if this update doesn't make sense to you. === As you might recall, the SNIPs need to be nice and small, but they need to be completely self-contained. The ENDIVE, on the other hand, needs to be diff-friendly, and compressible. Relays need to derive all the SNIPs from the ENDIVE. The ENDIVE and SNIP formats that I worked on during last week [SNIPFMT] was designed to meet these criteria. This week, I wrote up the algorithms to extract signed SNIPs from an ENDIVE. This is in section 4 [RECONST] of the specs in my work-in-progress repository [GITREPO] This was mainly straightforward consequence from the work I did last week, but there were a few things that turned up. One trickier aspect of this work is that we want to move most of the decision-making to the authorities, and have the relays simply do an expansion algorithm. Updating all the relays would be slow, so relays need to be able to handle new index types and data types without fully understanding them. That means that we need to specify an algorithm that can work flexibly with many future kinds of data. Another tricky aspect is that the data which the relays need to put into SNIPs all needs to be signed, so all of that data needs to come out the same when relays calculate it as the when the authorities calculate it. Thus, all the algorithms for building Merkle trees and indices and SNIPRouterData bodies need to be deterministic. I think that I got all of this relatively right in [RECONST], but there are probably some mistakes hiding in there. I'm hoping that there is a cleaner alternative to the weighted-index reconstruction algorithm -- the one that's there right now puts a lot of requirements on the input data, in order to avoid floating-point operations. === After working on ENDIVE expansion, I moved on to the problem of authorities voting. There's a lot of uncertainty here and decisions I'll need to make. The biggest decision is how the new voting process for ENDIVEs should relate to the current voting process for consensus documents. The choices seem to be: * Have two processes with different kinds of votes. * Expand the information that goes into current votes, and generate ENDIVEs as a new kind of consensus from the current voting process. * Design the ENDIVE voting process so that it can also be used to generate current-style consensuses. Using separate processes might be simplest, but it does carry risk for duplicated code, and for the two voting processes reaching divergent results. It would also be potentially bad if an authority could vote differently in each process. The second approach -- where ENDIVEs are another kind of consensus generated from current-style voting documents -- has some charm to it, but it perpetuates our current consensus-voting system, and makes us specify a second encoding of CBOR objects as text, if we want to vote on them meaningfully. This is a bit nasty, since the standard-specified text encoding of cbor is not a bijection, and doesn't mesh too well with our old directory format. Therefore the third approach seems a little better to me now. In it, we'd specify our votes as a CBOR-based format loosely based on the current vote format, and describe a way to extract from them the same data that is currently used for our voting algorithm. This would let us encode CBOR within the document naturally, while not having to throw away too much of our existing voting specification and voting code. I've got a few more ideas here, though I don't have any specs yet. I've been collecting the ideas in a notes file [VNOTES] so I don't forget them. === While working on voting notes, I found some areas where the ENDIVE and SNIP formats might be better. First, I hadn't thought about authority certificates. Those should go in, so that we can have the ENDIVE-signing keys be signed themselves with the authorities' long-lived identities. Second, there seem to be some opportunities for transmitting indices in a simpler way. Instead of assigning a weight to each router separately, for example, we could derive one weighted index from another weighted index by re-weighting it, as we do with the "bandwidth-weights" values in the current consensus. Teor also made some good suggestions for improving the diff format; I incorporated one and made a note to check the other. === I also spent a little while this week reading about BLS signatures, since they are the leading candidate for how we might do threshold signatures here. === Next week I'm going to try to get voting all specified. This will be a pretty deep dive, since I will need to maintain some backward compatibility with existing voting algorithms. There may be opportunities for simplification, however. === [GITREPO] https://github.com/nmathewson/walking-onions-wip [RECONST] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/04-recon… d [SNIPFMT] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/02-endiv… [VNOTES] https://github.com/nmathewson/walking-onions-wip/blob/master/notes/voting.t…

3 3

Walking onions status update: week 4 notes
by Nick Mathewson 30 Mar '20

30 Mar '20

Walking Onions: week 4 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories, binary diffs, metaformat decisions, and Merkle Tree trickery. https://lists.torproject.org/pipermail/tor-dev/2020-March/014178.html Week 2: Specifying details of SNIP and ENDIVE formats, in CDDL. https://lists.torproject.org/pipermail/tor-dev/2020-March/014181.html Week 3: Expanding ENDIVEs into SNIPs. https://lists.torproject.org/pipermail/tor-dev/2020-March/014194.html This week was pretty rough for me; the impact of being isolated at home is starting to kick in, and my kid is still trying to find a schedule that works for him. I got a lot less done this week than I had planned. That said, I _did_ get some good design done, in two areas: voting, and circuit extension. == Voting I'm trying to generalize our voting algorithms to minimize the need for new consensus formats in the future. I want most new fields to be self-describing in terms of how to tabulate votes for them. Trying to work this out has taken a bunch of energy, though and I'm not quite sure I'm doing it right. The work here is unfinished. I still think it's reasonable to encode existing votes and new votes in a new cbor-based structure. By using compression, a little redundancy in votes shouldn't hurt us too badly -- though that's something I need to benchmark eventually before we build this. I've come up with a way for voters to use diffs and compression when _uploading_ votes: first, the voter asks for a summary of what mechanisms are supported by the recipient and which older votes it has. Next, the voter can use that information to upload a vote diff with an appropriate compression format. Right now I believe that I have most of the fields for the votes figured out, but I need to clean them up a _lot_. SNIP bodies can work similarly to how microdescriptors work now, if we like -- or they could involve individual votes on input fields. I think I'm going to write up what I can here, and then revisit SNIP bodies once I've worked some on section 6 (the "fancy" client behavior). While working on voting, I found a need for various changes in the already written sections. For one example, the previous description of the ENDIVE format included the SNIP signatures as part of the signed ENDIVE. But we can't actually generate that as part our voting protocol: the authorities can't sign SNIPs until they know the complete ENDIVE contents, and so putting the SNIP signatures in the signed part of the ENDIVE would add an extra round of voting and signatures. Instead, I've moved the SNIP signatures (and related stuff) into the signature header of the ENDIVE. I've also worked somewhat on the so-called "root document" holding the network configuration parameters. I'm hoping that this document can have an effective lifetime of weeks or months for clients, and that clients can download only the parts that they need. The format is in section 02, but needs more description. The work-in-progress voting writeup is in [VOTING], but it is not so close to done. I think it will need a lot of writing before it's ready for even preliminary review; it doesn't make sense as it is, and it contradicts itself in places. == Extending circuits There are a few wrinkles here that we hadn't actually specified in earlier walking onions work! When one relay is told to extending a circuit to a target relay by index, the extending relay actually needs to include part of a SNIP for that second relay: otherwise, the extending relay won't know which onion key the client expects to receive for it. We don't want to send an entire SNIP -- only the parts that the client will expect to match. In addition to wide EXTEND cells, we'll also need wide RENDEZVOUS and INTRODUCE1 and INTRODUCE2 and TRUNCATED cells. All together, that means that having a general "cell fragmentation" mechanism is probably warranted; I've started a separate proposal for that [WIDE_EVERYTHING]. We're going to need a general extension format for CREATE and EXTEND cells, to signal other information, like SNIPs, requests for SNIPs, and so on. We also need a way to ask for SNIPs without actually performing a handshake. I've tried to fit these all together in a fairly logical way in [EXTENDING], but there's more to write here, including examples. == Fun facts The walking onion proposal is now the second-longest that we have ever had, behind only proposal 224 (v3 hidden services). == Next steps In this coming week I plan to try to wrap up section 3 on voting and section 5 on extending circuits. I'm going to go back to the start of section 2 and start revising all I've written so far for consistency. Time permitting, I want to sketch out all the knowns and unknowns for section 6 (on tricky client behavior). [EXTENDING] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/05-exten… [VOTING] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/02-votin… [WIDE_EVERYTHING] https://github.com/nmathewson/walking-onions-wip/blob/master/other-proposal…

2 1

Walking Onions status update: week 2 notes
by Nick Mathewson 29 Mar '20

29 Mar '20

Walking onions -- week 2 update Hi! On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send these out thee updates once a week, in case anybody is interested. My previous updates are linked below: Week 1: formats, preliminaries, git repositories, binary diffs, metaformat decisions, and Merkle Tree trickery. https://lists.torproject.org/pipermail/tor-dev/2020-March/014178.html You might like to have a look at that update, and its references, if this update doesn't make sense to you. === This week, I worked specifying the nitty-gritty of the SNIP and ENDIVE document formats. I used the CBOR meta-format [CBOR] to build them, and the CDDL specification language [CDDL] to specify what they should contain. As before, I've been working in a git repository at [GITHUB]; you can see the document I've been focusing on this week at [SNIPFMT]. (That's the thing to read if you want to send me patches for my grammar.) There were a few neat things to do here: * I had to define SNIPs so that clients and relays can be mostly agnostic about whether we're using a merkle tree or a bunch of signatures. * I had to define a binary diff format so that relays can keep on downloading diffs between ENDIVE documents. (Clients don't download ENDIVEs). I did a quick prototype of how to output this format, using python's difflib. * To make ENDIVE diffs as efficient as possible, it's important not to transmit data that changes in every ENDIVE. To this end, I've specified ENDIVEs so that the most volatile parts (Merkle trees and index ranges) are recomputed on the relay side. I still need to specify how these re-computations work, but I'm pretty sure I got the formats right. Doing this calculation should save relays a bunch of bandwidth each hour, but cost some implementation complexity. I'm going to have to come back to this choice going forward to see whether it's worth it. * Some object types are naturally extensible, some aren't. I've tried to err on the size of letting us expand important things in the future, and using maps (key->value mappings) for object that are particularly important. In CBOR, small integers are encoded with a little less space than small strings. To that end, I'm specifying the use of small integers for dictionary keys that need to be encoded briefly, and strings for non-tor and experimental extensions. * This is a fine opportunity to re-think how we handle document liveness. Right now, consensus directories have an official liveness interval on them, but parties that rely on consensuses tolerate larger variance than is specified in the consensus. Instead of that approach, the usable lifetime of each object is now specified in the object, and is ultimately controlled by the authorities. This gives the directory authorities more ability to work around network tolerance issues. Having large lifetime tolerances in the context of walking onions is a little risky: it opens us up to an attack where a hostile relay holds multiple ENDIVEs, and decides which one to use when responding to a request. I think we can address this attack, however, by making sure that SNIPs have a published time in them, and that this time moves monotonically forward. * As I work, I'm identifying other issues in tor that stand in the way of a good efficient walking onion implementation that will require other follow-up work. This week I ran into a need for non-TAP-based v2 hidden services, and a need for a more efficient family encoding. I'm keeping track of these in my outline file. Fun fact: In number of bytes, the walking onions proposal is now the 9th-longest proposal in the Tor proposal repository. And it's still growing! Next week, I'm planning to specify ENDIVE reconstruction, circuit extension, and maybe start on a specification for voting. [CBOR] RFC 7049: "Concise Binary Object Representation (CBOR)" https://tools.ietf.org/html/rfc7049b [CDDL] RFC 8610: "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures" https://tools.ietf.org/html/rfc8610 [GITREPO] https://github.com/nmathewson/walking-onions-wip [SNIPFMT] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/02-endiv…

3 6

Tails vs the capacity of the Meek bridges
by anonym 24 Mar '20

24 Mar '20

Hi, tl;dr: if Tails makes it too easy to use Meek bridges, could it overload the current set of Meek bridges? First some background: during startup Tails can be told to start Tor Launcher so users can e.g. configure any bridges they want. So far we have not provided any pre-configured bridges, i.e. the only option has been to manually enter the bridge information you have obtained yourself. In Tails' threat model it is assumed that adversaries monitor the default bridges provided by the Tor Browser, and that our users want to avoid detection of that, so we are not interested in adding the default bridges to Tails, but we are interested in adding support for Meek [1] (at least because it's the only PT that works in China), since our understanding is that it adds enough plausible deniability to avoid the above problem. So, in summary, Tails would like to provide two options in its (patched) Tor Launcher, Meek or manually providing the bridge info. [2] However, we wonder if the combination of not providing the default bridges while making Meek available could overwhelm the Meek bridges; we expect some significant amount of Tails bridge users to select the Meek option over manual entry simply out of convenience. Let's do some back-of-the-envelope estimations to see what we can expect: (Assumption: Tor Browser users and Tails users are very similar, e.g. similar ratios want to use each PT, similar requirements for "convenience over security", and so on.) Looking at your metrics, there are 1000k daily Tor Browser users [3], overall bridge/PT usage is 50k [4], Meek usage is around 10k [5], so 5% of Tor Browser users use bridges/PTs, and 1% use Meek. On the Tails side, we measure around 30k daily users (from update pings). >From what I said above, I don't think we can expect only 1% of the Tails users to pick Meek; I would expect it to be closer to the 1% of Meek users plus the x% of default bridge users, but I couldn't find stats for that in your metrics. Still, we know that it cannot be more than the percentage of all bridge/PT users, so we know that 1% + x% <= 5%. So, let's just assume the worst case, that 5% of Tails users will use Meek, and we have that we expect 5% of 30k = 1.5k additional Meek users. Also, if we consider places where Meek is the only options, Tails probably has close to zero users there, but once Meek is supported it could grow. I guess China is the only such place (?), so with its 1250 Meek users in China [6] we can expect 1250 * 30k/1000k = 34 new Tails users using Meek. Basically a negligible amount. Even if we consider all Meek users, 10k * 30k/1000k = 300 doesn't change much. So, all-in-all, we can expect Tails to bring up to 1.5k + 300 = 1.8k new Meek users, but since those are upper-bound estimations it would probably be much lower. Looking on Meek usage over time, it seems to fluctuate way more than that, e.g. during the summer of 2019 it was up to over 25k, i.e. more than three times what it is now. So I guess we don't have to worry about shocking the Meek bridges? OTOH, a possible side-effect is that this change in Tails increases usage of Meek outside of China. Perhaps whoever pays the bills for the Meek instances don't want this? Please advice! Also, please let us know if there is something else we haven't thought of! Cheers! [1] https://redmine.tails.boum.org/code/issues/8243 [2] If you are really interested you can check out our PoC/WIP here: https://nightly.tails.boum.org/build_Tails_ISO_feature-8243-meek/builds/las… [3] https://metrics.torproject.org/webstats-tb.html [4] https://metrics.torproject.org/userstats-bridge-transport.html [5] https://metrics.torproject.org/userstats-bridge-transport.html?transport=!%… [6] https://metrics.torproject.org/userstats-bridge-combined.html?start=2019-12…

4 5