December 2017 - tor-dev - lists.torproject.org

IPv6 and v3 onion services
by teor 14 Dec '17

14 Dec '17

Hi David (and others interested in IPv6), We want to add better IPv6 support to Tor relays, clients, and v3 onion services. But if we do IPv6 v3 onion services first, the hop before intro and rend points will know that the circuit is a v3 onion service circuit, because its EXTEND2 cells will have an IPv6 address. So I suggest that we implement IPv6 support in this order: IPv6 single onion services (at any time, only uses direct IPv6 CREATE) IPv6 relay extends IPv6 relay reachability (provides cover traffic for IPv6 client extends) IPv6 client extends for exit circuits IPv6 client extends for multi-hop onion service circuits I've added this to an "Overview" section in: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features I also like the idea of testing and deploying our IPv6 code on relays first. It's less risky than experimenting on clients or onion services. And our relay operators give us some excellent bug reports. And we can re-use some of the common code from the relay implementation in the client and onion service implementations. (For example, we'll write code that handles link specifiers.) Also, if we get IPv6 relay reachability checks working, that makes it easier to automatically configure IPv6 on relays. More IPv6 relays will make the anonymity set larger for IPv6 clients. What do you think? T

2 5

Proposal 249 updated
by isis agora lovecruft 14 Dec '17

14 Dec '17

Hi all! I've revised prop#249 (I think) according to the discussion from [0,1,2,3]. The revised proposal is in torspec, [4] but for convenience it's included inline below. Please review and hopefully catch any dumb mistakes I made. It looks like implementing this is going to be a bit of a chore, so I'm guessing it would be better to target 0.3.4.x than 0.3.3.x? [0]: https://lists.torproject.org/pipermail/tor-dev/2017-December/012665.html [1]: https://lists.torproject.org/pipermail/tor-dev/2017-December/012688.html [2]: http://meetbot.debian.net/tor-meeting/2017/tor-meeting.2017-12-13-22.03.html [3]: https://pad.riseup.net/p/r.1c4c37baa9251fdfca5a1e1bd5c01f45 [4]: https://gitweb.torproject.org/torspec.git/tree/proposals/249-large-create-c… Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt Filename: 249-large-create-cells.txt Title: Allow CREATE cells with >505 bytes of handshake data Authors: Nick Mathewson, Isis Lovecruft Created: 23 July 15 Updated: 13 December 2017 Status: Open 1. Summary There have been multiple proposals over the last year or so for adding post-quantum cryptography to Tor's circuit extension handshakes. (See for example https://eprint.iacr.org/2015/008 or https://eprint.iacr.org/2015/287 .) These proposals share the property that the request and reply for a handshake message do not fit in a single RELAY cell. In this proposal I describe a new CREATE2V cell for handshakes that don't fit in a 505-byte CREATE2 cell's HDATA section, and a means for fragmenting these CREATE2V cells across multiple EXTEND2 cells. I also discuss replies, migration, and DoS-mitigation strategies. 2. CREATE2V and CREATED2V First, we add two variable-width cell types, CREATE2V and CREATED2V. These cell formats are nearly the same as CREATE2 and CREATED2. (Here specified using Trunnel.) struct create2v_cell_body { /* Handshake type */ u16 htype; /* Length of handshake data */ u16 hlen; /* Handshake data */ u8 hdata[hlen]; /* Padding data to be ignored */ u8 ignored[]; }; struct created2v_cell_body { /* Handshake reply length */ u16 hlen; /* Handshake reply data */ u8 hdata[hlen]; /* Padding data to be ignored */ u8 ignored[]; }; The 'ignored' fields, which extend to the end of the variable-length cells, are reserved. Initiators MAY set them to any length, and MUST fill them with either zero-valued bytes or pseudo-random bytes. Responders MUST ignore them, regardless of what they contain. When a CREATE2V cell is generated in response to a set of EXTEND2 cells, these fields are set by the relay that receives the EXTEND2 cells. (The purpose of the 'ignored' fields here is future-proofing and padding.) Protocols MAY wish to pad to a certain multiple of bytes, or wish to pad the initiator/receiver payloads to be of equal length. This is encouraged but NOT REQUIRED. 3. Fragmented EXTEND2 cells Without changing the current EXTEND2 cell format, we change its semantics: If the 'HLEN' field in an EXTEND2 cell describes a handshake data section that would be too long to fit in the EXTEND2 cell's payload, the handshake data of the EXTEND2 cell is to be continued in one or more subsequent EXTEND2 cells. These subsequent cells MUST have zero link specifiers, handshake type 0xFFFF, and handshake data length field set to zero. Similarly, if the 'HLEN' field in an EXTENDED2 cell would be too long to fit into the EXTENDED2 cell's payload, the handshake reply data of the EXTENDED2 cell is to be continued in one or more subsequent EXTENDED2 cells. These subsequent cells must have the handshake data length field set to zero. These cells must be sent on the circuit with no intervening cells. If any intervening cells are received, the receiver SHOULD destroy the circuit. Protocols which make use of CREATE(D)2V cells SHOULD send an equal number of cells in either direction, to avoid trivially disclosing information about the direction of the circuit: for example a relay might use the fact that it saw five EXTEND2 cells in one direction and three in the other to easily determine whether it is the middle relay on the onion service-side or the middle relay on the client-side of a rendezvous circuit. 4. Interacting with RELAY_EARLY cells The first EXTEND2 cell in a batch must arrive in a RELAY_EARLY cell. The others MAY arrive in RELAY_EARLY cells. For many handshakes, for the possible lengths of many types of circuits, sending all EXTEND2 cells inside RELAY_EARLY cells will not be possible. For example, for a fragmented EXTEND2 cell with parts A B C D E, A is the only fragment that MUST be sent within a RELAY_EARLY. For parts B C D E, these are merely sent as EXTEND2{CREATE2V} cells. Note that this change leaks the size of the handshake being used to intermediate relays. We should analyze this and see whether it matters. Clients and relays MAY send RELAY_DROP cells during circuit construction in order to hide the true size of their handshakes (but they can't send these drop cells inside a train of EXTEND2 or EXTENDED2 cells for a given handshake). 5. Example So for example, if we are a client, and we need to send a 2000-byte handshake to extend a circuit from relay X to relay Y, we might send cells as follows: EXTEND2 { nspec = 2; lstype = [0x01 || 0x02]; (IPv4 or IPv6 node address) lslen = [0x04 || 0x16]; lspec = { node address for Y, taking 8 bytes or 16 bytes}; lstype = 0x03; (An ed25519 node identity) lslen = 32; lspen = { ed25519 node ID for Y, taking 32 bytes } htype = {whatever the handshake type is.} hlen = 2000 hdata = { the first 462 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the final 62 bytes of the handshake } } Upon receiving this last cell, the relay X would send a create2v cell to Y, containing the entire handshake. 6. Migration We can and should implement the EXTEND2 fragmentation feature before we implement anything that uses it. If we can get it widely deployed before it's needed, we can use the new handshake types whenever both of the involved relays support this proposal. Clients MUST NOT send fragmented EXTEND2 cells to relays that don't support them, since this would cause them to close the circuit. Relays MAY send CREATE2V and CREATED2V cells to relays that don't support them, since unrecognized cell types are ignored. 6.1. New Subprotocols and Subprotocol Versions This proposal introduces, following prop#264, the following new subprotocol numbers and their uses. 6.1.1. Relay Subprotocol "Relay 3" -- The OP supports all of "Relay 2", plus support for CREATE2V and CREATED2V cells and their above specification for link-layer authentication specifiers. 6.1.2. Link Subprotocol "Link 5": The OP supports all of "Link 1-4", plus support for the new EXTEND2 semantics. Namely, it understands that an EXTEND2 cell whose "hlen" field is greater than 505 will be followed by further "hdata" in fragmented EXTEND2 cells which MUST follow. It also understands that the following combination of EXTEND2 payload specifiers indicates that the cell is a continuation of the earlier payload portions: nspec = 0; htype = 0xffff; hlen = 0; 6.1.3. Handshake Subprotocol Additionally, we introduce a new subprotocol, "Handshake" and the following number assignments for previously occuring instances: "Handshake 1" -- The OP supports the TAP handshake. "Handshake 2" -- The OP supports the ntor handshake. We also reserve the following assignments for future use: "Handshake 3" -- The OP supports the "hybrid+null" ntor-like handshake from prop#269. "Handshake 4" -- The OP supports a(n as yet unspecified) post-quantum secure hybrid handshake, that is, the "hybrid+null" handshake from "Handshake 3", except with "null" part replaced with another (as yet unspecified) protocol to be composed with the ntor-like ECDH-based handshake. Further handshakes MUST be specified with "Handshake" subprotocol numbers, and MUST NOT be specified with "Relay" subprotocol numbers. The "Relay" subprotocol SHALL be used in the future to denote changes to handshake protocol handling of CREATE* and EXTEND* cells, i.e. CREATE, CREATED, CREATE_FAST, CREATED_FAST, CREATE2, CREATED2, CREATE2V, CREATED2V, EXTEND, EXTENDED, EXTEND2, and EXTENDED2. Thus, "Handshake 1" is taken to be synonymous with "Relay 1", and likewise "Handshake 2" is with "Relay 2". 6.2. Subprotocol Recommendations After the subprotocol additions above, we change to recommending the following in the consensus: recommended-client-protocols […] Link=5 Relay=3 Handshake=2 recommended-relay-protocols […] Link=5 Relay=3 Handshake=2 required-client-protocols […] Link=4-5 Relay=2-3 Handshake=1-2 required-relay-protocols […] Link=3-5 Relay=1-3 Handshake=1-2 6.2. New Consensus Parameters We introduce the following new consensus parameters: Create2VMaximumData SP int The maximum amount of "hlen" data, in bytes, which may carried in either direction within a set of CREATE(D)2V cells. (default: 10240) 7. Resource management issues This feature requires relays and clients to buffer EXTEND2 cell bodies for incoming cells until the entire CREATE2V/CREATED2V body has arrived. To avoid memory-related denial-of-service attacks, the buffers allocated for this data need to be counted against the total data usage of the circuit. Further, circuits which receive and buffer CREATE(D)2V cells MUST store the time the first buffer chunk was allocated, and use it to inform the OOM manager w.r.t. the amount of data used and its staleness. Appendix A. A rejected idea for migration In section 5 above, I gave up on the idea of allowing relay A to extend to relay B with a large CREATE cell when relay A does not support this proposal. There are other ways to do this, but they are impressively kludgey. For example, we could have a fake CREATE cell for new handshake types that always elicits a "yes, keep going!" CREATED cell. Then the client could send the rest of the handshake and receive the rest of the CREATED cell as RELAY cells inside the circuit. This design would add an extra round-trip to circuit extension whenever it was used, however, and would violate a number of Tor's assumptions about circuits (e.g., by having half-created circuits, where authentication hasn't actually been performed). So I'm guessing we shouldn't do that.

2 1

Discussion Meeting for Prop#249 "Large CREATE cells"
by isis agora lovecruft 13 Dec '17

13 Dec '17

Hello all, What: A proposal discussion meeting for prop#249 "Allow CREATE cells with >505 bytes of handshake data". [0] Who: This proposal is likely of interest to those hoping to integrate newer, non-ECC-based, circuit-layer handshakes into the Tor protocol. When: Next week, on Monday or Tuesday (or Wednesday, for some timezones). If you'd like to attend, please vote on a time here: https://doodle.com/poll/v924cbt2at3rzvc9 Where: irc.oftc.net #tor-meeting [0]: https://gitweb.torproject.org/torspec.git/tree/proposals/249-large-create-c… Meeting Preparation Materials ============================= The following is meant for attendees to refresh before the meeting. Please feel free to respond with further summary and/or open questions/concerns. Proposal Summary ~~~~~~~~~~~~~~~~ The proposal outlines two new cell types, CREATE2V and CREATED2V, which are variable-length and (like their CREATE2/CREATED2 counterparts) are sent encapsulated in EXTEND2 cells. Due to their variable-length, however, if a CREATE(D)2V cell's HDATA is larger than the standard allotment of 505 bytes, these new cells are fragmented across multiple EXTEND2 cells. Open Questions/Concerns ~~~~~~~~~~~~~~~~~~~~~~~ 1. Since CREATE2V cells are used for handshakes, and several newer, post-quantum primitives have asymmetric payloads for the client versus server directions, should we require that the CREATE(D)2V padding be used to equalise the number of bytes sent in each direction? 2. Should we randomise the bytes in the padding? (Currently, as proposed, we require all-zero padding.) 3. Should we do anything more future-proofed w.r.t. the future possibility of using an alternate (non-stateful, e.g. not TCP) transport? (Currently, the proposal relies heavily upon the transport-layer to provide delivery guarantee and, perhaps more important, ordering.) 4. Shoule we, for hybrid handshakes (handshakes which use multiple separate primitives to derive shared secrets, e.g. ECDH+RLWE or ECDH+SIDH, by conducting each handshake separately and composing their respective resulting shared secrets), design some mechanism where, if a party only supports say the ECDH portion of the hybrid handshake and not the RLWE part, then they proceed with the portion they understand? For example, a client sends their portion of a ECDH+RLWE handshake to a relay which only understands ECDH, so the relay responds with only ECDH and they continue. This is mostly a difference in subprotocol versioning for handshakes, that is, an ECDH+RLWE handshake, rather than being "handshake type 5" or whatever, would be "handshake type 2 AND/OR handshake type 5". 5. As written, the proposal doesn't specify a maximum (or minimum) size of handshake data. However, the max is somewhat limited by the number of allowed RELAY_EARLY cells; maximum handshake data is then limited to 462+(7*492)=3906 bytes. Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

3 4

Proposal 287: Reduce circuit lifetime without overloading the network.
by Fernando Fernández Mancera 12 Dec '17

12 Dec '17

Hello, I have been working on this proposal for some time and Nick blessed me to send it as Proposal 287. Here is. Filename: 287-reduce-lifetime.txt Title: Reduce circuit lifetime without overloading the network Author: Fernando Fernandez Mancera Created: 30-Nov-2017 Status: Open Motivation: Currently Tor users are reusing a given circuit for ten minutes (by default) after it's first used. This time is too long because a malicious Exit relay can trace a user's pseudonymous profile, especially if connections from multiple protocols are put on the same circuit. This time it is established on MaxCircuitDirtiness parameter and by default its value is ten minutes. I have been thinking in a way to fix this. The first idea that came to my mind was to use StreamIsolationByHost and StreamIsolationByPort on it, but I wasn't able to sort it out. One day, I thought "Why is time so important?" and later on I realized that maybe focusing on the amount of bytes running through the circuit could end up being a better approach on this problem. Design: I propose two options to reduce this problem, both based on taking into account the amount of bytes running through a circuit. MaxCircuitSizeDirtiness (temporal parameter name) will take an integer field that is contained on an interval and represents the maximum amount of bytes that can be written/read (we need to discuss about the use of one for both) by the circuit. If the circuit exceeds that amount, new streams won't use this circuit anymore. MaxCircuitSizeDirtinessByPort (temporal parameter name) will take an array of integers that are contained on an interval and represents the maximum amount of bytes that can be written/read (we need to discuss about the use of one for both) by the circuit per port (StreamIsolationByPort). This array is parallel to the array of ports from StreamIsolationByPort. If the circuit exceeds that amount, new streams won't use this circuit anymore. Regarding default values it would be useful to set up one a bit lower than the average amount of bytes per circuit. On MaxCircuitSizeDirtinessByPort after discuss it we shouldn't set up a default value because someone can identify the port used. About MaxCircuitDirtiness, if the others are set up by default it could be bigger, like thirty minutes, so if the user doesn't send/receive a significant amount of data the circuit will be changed anyway. Security Implications: It is believed that the proposed changes will improve the anonymity for end users. The end user won't reuse a given circuit if they have sent a considerable amount of bytes, thus making more difficult for malicious Exit relays to be able to trace a user's pseudonymous profile. Obviously this is a probability, of course it's possible that sensitive data will leak in a little amount of data but it's more even possible that sensitive data will leak in a large amount. Specification: In order to implement this feature we will need to add some new functionalities. We need to parse MaxCircuitSizeDirtiness and MaxCircuitSizeDirtinessByPort from the torrc config file. We need to create a function or improve one to check the amount of bytes that are running through the circuit and if this amount is higher than the established value, consider the circuit dirty. Compatibility: The proposed changes should not create any compatibility issues. New Tor clients will be able to take advantage of this without any modification to the network. Implementation: It is proposed that MaxCircuitSizeDirtiness will be enabled by default and also increase MaxCircuitDirtiness to thirty minutes. It is proposed that MaxCircuitSizeDirtinessByPort won't be enabled by default for port 22, 53, and port 80 as StreamIsolationByPort. About TorBrowser or any other Tor application that is able to manage circuits by its own because of KeepAliveIsolateSOCKSAuth option being active by default shouldn't be affected by this new feature. As the same form that it currently ignores MaxCircuitDirtiness parameter. Performance and scalability notes: The proposed changes will reduce Tor network stress as users who do not exceed the set amount will reduce circuit generation by three (if default MaxCircuitDirtinesss value is thirty minutes). I want to work on demonstrating that by a research but first it's nice to get the idea accepted. References: Tor project research ideas [https://research.torproject.org/ideas.html] Enhancing Tor's Performance using Real-time Traffic Classification [https://www.cypherpunks.ca/~iang/pubs/difftor-ccs.pdf] (It's not exactly about that, but they talk about circuit lifetime and the ten minutes problem a few times. Also it's an interesting paper.)

3 8

How about capping single operators to max. 10% exit capacity of the network?
by nusenu 11 Dec '17

11 Dec '17

Hi, since a single operator now controls more than 10% of the tor network's exit capacity I wanted to bring this up here (again [1]). What do you think about capping single operators (family) to 10% exit capacity and 5% for guard operators? regards, nusenu [1] https://lists.torproject.org/pipermail/tor-dev/2016-March/010653.html -- https://mastodon.social/@nusenu twitter: @nusenu_

3 7

Proposal 286: Controller APIs for hibernation access on mobile
by Nick Mathewson 08 Dec '17

08 Dec '17

Filename: 286-hibernation-api.txt Title: Controller APIs for hibernation access on mobile Author: Nick Mathewson Created: 30-November-2017 Status: Open 1. Introduction On mobile platforms, battery life is achieved by reducing needless network access and CPU access. Tor currently provides few ways for controllers and operating systems to tune its behavior. This proposal describes controller APIs for better management of Tor's hibernation mechanisms, and extensions to those mechanisms, for better power management in mobile environments. 1.1. Background: hibernation and idling in Tor today We have an existing "hibernation" mechanism that we use to implement "bandwidth accounting" and "slow shutdown" mechanisms: When a Tor instance is close to its bandwidth limit: it stops accepting new connections or circuits, and only processes those it has, until the bandwidth limit is reached. Once the bandwidth limit is reached, Tor closes all connections and circuits, and all non-controller listeners, until a new accounting limit begins. Tor handles the INT signal on relays similarly: it stops accepting new connections or circuits, and gives the existing ones a short interval in which to shut down. Then Tor closes all connections and exits the process entirely. Tor's "idle" mechanism is related to hibernation, though its implementation is separate. When a Tor clients has passed a certain amount of time without any user activity, it declares itself "idle" and stops performing certain background tasks, such as fetching directory information, or building circuits in anticipation of future needs. (This is tied in the codebase to the "predicted ports" mechanism, but it doesn't have to be.) 1.2. Background: power-management signals on mobile platforms (I'm not a mobile developer, so I'm about to wildly oversimplify. Please let me know where I'm wrong.) Mobile platforms achieve long battery life by turning off the parts they don't need. The most important parts to turn off are the antenna(s) and the screen; the CPU can be run in a slower mode. But it doesn't do much good turning things off when they're unused, if some background app is going to make sure that they're always in use! So mobile platforms use signals of various kinds to tell applications "okay, shut up now". Some apps need to do online background activities periodically; to help this out, mobile platforms give them a signal "Hey, now is a good time if you want to do that" and "stop now!" 1.3. Mostly out-of-scope: limiting CPU wakeups when idle. The changes described here will be of limited use if we do not also alter Tor so that, when it's idle, the CPU is pretty quiet. That isn't the case right now: we have large numbers of callbacks that happen periodically (every second, every minute, etc) whether they need to or not. We're hoping to limit those, but that's not what this proposal is about. 2. Improvements to the hibernation model To present a consistent interface that applications and controllers can use to manage power consumption, we make these enhancements to our hibernation model. First, we add three new hibernation states: "IDLE", "IDLE_UPDATING", "SLEEP", and "SLEEP_UPDATING". "IDLE" is like the current "idle" or "no predicted ports" state: Tor doesn't launch circuits or start any directory activity, but its listeners are still open. Tor clients can enter the IDLE state on their own when they are LIVE, but haven't gotten any client activity for a while. Existing connections and circuits are not closed. If the Tor instance receives any new connections, it becomes LIVE. "IDLE_UPDATING" is like IDLE, except that Tor should check for directory updates as appropriate. If there are any, it should fetch directory information, and then become IDLE again. "SLEEPING" is like the current "dormant state we use for bandwidth exhaustion, but it is controller-initiated: it begins when Tor is told to enter it, and ends when Tor is told to leave it. Existing connections and circuits are closed; listeners are closed too. "SLEEP_UPDATING" is like SLEEP, except that Tor should check for directory updates as appropriate. If there are any, it should fetch directory information, and then SLEEP again. 2.1. Relay operation Relays and bridges should not automatically become IDLE on their own. 2.2. Onion service operation When a Tor instance that is running an onion service is IDLE, it does the minimum to try to remain responsive on the onion service: It keeps its introduction points open if it can. Once a day, it fetches new directory information and opens new introduction points. 3. Controller hibernation API 3.1. Examining the current hibernation state We define a new "GETINFO status/hibernation" to inspect the current hibernation state. Possible values are: - "live" - "idle:control" - "idle:no-activity" - "sleep:control" - "sleep:accounting" - "idle-update:control" - "sleep-update:control" - "shutdown:exiting" - "shutdown:accounting" - "shutdown:control" The first part of each value indicates Tor's current state: "live" -- completely awake "idle" -- waiting to see if anything happens "idle-update" -- waiting to see if anything happens; probing for directory information "sleep" -- completely unresponsive "shutdown" -- unresponsive to new requests; still processing existing requests. The second part of each value indicates the reason that Tor entered this state: "control" -- a controller told us to do this. "no-activity" -- Tor became idle on its own due to not noticing any requests. "accounting" -- the bandwidth system told us to enter this state. "exiting" -- Tor is in this state because it's getting ready to exit. We add a STATUS_GENERAL hibernation event as follows: HIBERNATION "STATUS=" (one of the status pairs above.) Indicates that Tor's hibernation status has changed. Note: Controllers MUST accept status values here that they don't recognize. The "GETINFO accounting/hibernating" value and the "STATUS_SERVER HIBERANATION_STATUS" event keep their old meaning. 3.2. Changing the hibernation state We add the following new possible values to the SIGNAL controller command: "SLEEP" -- enter the sleep state, after an appropriate shutdown interval. "IDLE" -- enter the idle state "SLEEPWALK" -- If in sleep or idle, start probing for directory information in the sleep-update or idle-update state respectively. Remain in that state until we've probed for directory information, or until we're told to IDLE or SLEEP again, or (if we're idle) until we get client activity. Has no effect if not in sleep or idle. "WAKEUP" -- If in sleep, sleep-update, idle, idle-update, or shutdown:sleep state, enter the live state. Has no effect in any other state. 3.3. New configuration parameters StartIdle -- Boolean. If set to 1, Tor begins in IDLE mode.

5 8

Student project to work on IPv6 support (was: [tor-relays] About relay size)
by Santiago R.R. 06 Dec '17

06 Dec '17

(Moving this thread from tor-relay) El 03/10/17 a las 14:25, teor escribió: > > > On 3 Oct 2017, at 10:57, Roman Mamedov <rm(a)romanrm.net> wrote: > > > > On Tue, 3 Oct 2017 09:53:46 -0400 > > teor <teor2345(a)gmail.com> wrote: > > > >>> For interposing dual-protocoled nodes along the way, how many do there > >>> have to be for it to become "not too limiting"? > >> > >> This is one of the questions we need researchers to answer. > > > > I can't help but feel you are overcomplicating this. > > > > Clients create a circuit by randomly picking 3 nodes out of the all-nodes > > pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over > > IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are > > IPv4-only, the whole selection can be thrown away and repeated. > > > > That way IPv6-only relays could get some usage on a totally random basis, with > > no compromises and no restraining "of the next hop based on the previous one", > > not hurting anonymity. Clients just need to know which nodes are IPv4-only, > > IPv6-only or dual-stack, to not attempt unworkable combinations, discarding > > them instead. > > Discarding unworkable combinations and restraining node choices seem > equivalent to me, although the relay weights may be different. > > > And as there are more and more dual-stack or IPv6-only relays, the "throw > > away" step will be needed less and less often. > > If you think this will work and is safe for client anonymity, then the next step > is to write a tor proposal. Having a concrete design could help with > analysing the anonymity implications as well. > > I think IPv6-only relays are a lower priority than better IPv6 and dual-stack > client support, and IPv6-only bridge support But we could do both in the > same release. Hello tor-dev, With my colleague JC Bach (in CC), we have proposed a last-year student project to address IPv6-related issues in Tor for the upcoming semester, at IMT Atlantique engineering school. There will be two students working on it. It is hard to say now how far we will arrive, especially because this is our first approach to Tor entrails. So this message is to say we have good chances to come back here looking for help :-) Cheers, -- Santiago

2 4

Rebooting work on proposal #247 (guard discovery)
by George Kadianakis 06 Dec '17

06 Dec '17

Hello Mike, I'm finally getting out of the prop224/microdescriptor bug pile, and getting more time to start working on guard stuff like prop247 again. I'm planning to spend a few days next week to regain knowledge on prop247. I'll check out the notes from the Wilmington hackfest, re-read my old simulator's code, etc. I know you have thought more about prop247 the past months, and it would be great if you could brief me up on any updates that I should know about. Specifically I'm wondering if you have any new insights on how the proposed prop247 changes interact with Tor's guard algorithm (prop271)? Also any other things I should know about from your work on the performance simulator? Perhaps ideas about performance, topology or path restrictions? I'm hoping that such updates might help me boot up faster! Cheers! :-)

2 2

Names for your Onions: Onion addresses in SSL certificates
by heddha 06 Dec '17

06 Dec '17

Dear list, I wrote an addon as a PoC for idea 3 of the blogpost in [0]. The idea was to extend the Tor Browser by a means of reading out the C/O/S/L fields of the SSL certificate, and, if a website contains an onion address in one of those fields, to automatically redirect users to it. As the web-extensions API doesn't contain a means of reading out certificate information [1], I implemented it as an add-on. You can find it here: [2]. As stated in the blog post, all fields mentioned above could theoretically be filled with an onion address. Unfortunately, I found a large drawback: A certificate from Letsencrypt doesn't contain the C/S/O/L fields, as Letsencrypt performs a validation of required fields only, and the subject field isn't required. All unvalidated fields are by default not included in the certificate [3]. It is therefore not possible to include an onion address in the proposed fields using Letsencrypt; these are only filled when extended validation is performed (during which the correctness of the entries seems to be validated as well). Non-organisational suppliers of websites will therefore not be able to include their onion addresses in their normal certificate, which will most likely limit the amount of certificates containing onion addresses to a few larger organisations (if any). To make this idea actually usable for a large amount of people, one would have or to use another field, the content of which is neither checked nor deleted from a certificate, or introduce a new field =) Kind regards, heddha [0]: https://blog.torproject.org/cooking-onions-names-your-onions [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1322748 [2]: https://github.com/heddha/sslOnions [3]: https://community.letsencrypt.org/t/maintain-subject-records-country-etc-in…

1 0

Start contributing to Tor
by Aruna Maurya 04 Dec '17

04 Dec '17

I am new to the community and would like to contribute and help along. I did a complete read up on how the Tor browser works, but I would like to delve in more and get acquainted with the code base, so that I understand and learn a lot in the process. I already cloned and built the Tor(core) and TorBrowser from source for easy understanding and primarily as it would help me to reproduce bugs as I work on them. Any further guidance is appreciated. Thankyou for spending the time to read this through. -- Regards, Aruna Maurya, CSE,B.tech, Blog <https://themindreserves.wordpress.com/> | Medium <https://medium.com/@arunamaurya>

3 4