diff options
Diffstat (limited to 'proposals')
| -rw-r--r-- | proposals/000-index.txt | 52 | ||||
| -rw-r--r-- | proposals/098-todo.txt | 4 | ||||
| -rw-r--r-- | proposals/099-misc.txt | 5 | ||||
| -rw-r--r-- | proposals/265-load-balancing-with-overhead.txt | 27 | ||||
| -rw-r--r-- | proposals/282-remove-named-from-consensus.txt | 2 | ||||
| -rw-r--r-- | proposals/285-utf-8.txt | 2 | ||||
| -rw-r--r-- | proposals/291-two-guard-nodes.txt | 2 | ||||
| -rw-r--r-- | proposals/308-counter-galois-onion.txt | 10 | ||||
| -rw-r--r-- | proposals/324-rtt-congestion-control.txt | 7 | ||||
| -rw-r--r-- | proposals/327-pow-over-intro.txt | 12 | ||||
| -rw-r--r-- | proposals/329-traffic-splitting.txt | 2 | ||||
| -rw-r--r-- | proposals/332-ntor-v3-with-extra-data.md | 2 | ||||
| -rw-r--r-- | proposals/336-randomize-guard-retries.md | 8 | ||||
| -rw-r--r-- | proposals/337-simpler-guard-usability.md | 2 | ||||
| -rw-r--r-- | proposals/344-protocol-info-leaks.txt | 1186 | ||||
| -rw-r--r-- | proposals/345-specs-in-mdbook.md | 254 | ||||
| -rw-r--r-- | proposals/BY_INDEX.md | 24 | ||||
| -rw-r--r-- | proposals/README.md | 24 |
18 files changed, 1558 insertions, 67 deletions
diff --git a/proposals/000-index.txt b/proposals/000-index.txt index c251c90..48765d0 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -18,8 +18,8 @@ Proposals by number: 000 Index of Tor Proposals [META] 001 The Tor Proposal Process [META] -098 Proposals that should be written [META] -099 Miscellaneous proposals [META] +098 Proposals that should be written [OBSOLETE] +099 Miscellaneous proposals [OBSOLETE] 100 Tor Unreliable Datagram Extension Proposal [DEAD] 101 Voting on the Tor Directory System [CLOSED] 102 Dropping "opt" from the directory format [CLOSED] @@ -185,7 +185,7 @@ Proposals by number: 262 Re-keying live circuits with new cryptographic material [RESERVE] 263 Request to change key exchange protocol for handshake v1.2 [OBSOLETE] 264 Putting version numbers on the Tor subprotocols [CLOSED] -265 Load Balancing with Overhead Parameters [ACCEPTED] +265 Load Balancing with Overhead Parameters [OPEN] 266 Removing current obsolete clients from the Tor network [SUPERSEDED] 267 Tor Consensus Transparency [OPEN] 268 New Guard Selection Behaviour [OBSOLETE] @@ -211,7 +211,7 @@ Proposals by number: 288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version) [RESERVE] 289 Authenticating sendme cells to mitigate bandwidth attacks [CLOSED] 290 Continuously update consensus methods [META] -291 The move to two guard nodes [NEEDS-REVISION] +291 The move to two guard nodes [FINISHED] 292 Mesh-based vanguards [ACCEPTED] 293 Other ways for relays to know when to publish [CLOSED] 294 TLS 1.3 Migration [DRAFT] @@ -228,7 +228,7 @@ Proposals by number: 305 ESTABLISH_INTRO Cell DoS Defense Extension [CLOSED] 306 A Tor Implementation of IPv6 Happy Eyeballs [OPEN] 307 Onion Balance Support for Onion Service v3 [RESERVE] -308 Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography [OPEN] +308 Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography [SUPERSEDED] 309 Optimistic SOCKS Data [OPEN] 310 Towards load-balancing in Prop 271 [CLOSED] 311 Tor Relay IPv6 Reachability [ACCEPTED] @@ -244,26 +244,28 @@ Proposals by number: 321 Better performance and usability for the MyFamily option (v2) [ACCEPTED] 322 Extending link specifiers to include the directory port [OPEN] 323 Specification for Walking Onions [OPEN] -324 RTT-based Congestion Control for Tor [OPEN] +324 RTT-based Congestion Control for Tor [FINISHED] 325 Packed relay cells: saving space on small commands [OBSOLETE] 326 The "tor-relay" Well-Known Resource Identifier [OPEN] -327 A First Take at PoW Over Introduction Circuits [DRAFT] +327 A First Take at PoW Over Introduction Circuits [FINISHED] 328 Make Relays Report When They Are Overloaded [CLOSED] -329 Overcoming Tor's Bottlenecks with Traffic Splitting [NEEDS-REVISION] +329 Overcoming Tor's Bottlenecks with Traffic Splitting [FINISHED] 330 Modernizing authority contact entries [OPEN] 331 Res tokens: Anonymous Credentials for Onion Service DoS Resilience [DRAFT] -332 Ntor protocol with extra data, version 3 [FINISHED] +332 Ntor protocol with extra data, version 3 [CLOSED] 333 Vanguards lite [FINISHED] 334 A Directory Authority Flag To Mark Relays As Middle-only [SUPERSEDED] 335 An authority-only design for MiddleOnly [CLOSED] -336 Randomized schedule for guard retries [ACCEPTED] -337 A simpler way to decide, "Is this guard usable?" [ACCEPTED] +336 Randomized schedule for guard retries [CLOSED] +337 A simpler way to decide, "Is this guard usable?" [CLOSED] 338 Use an 8-byte timestamp in NETINFO cells [ACCEPTED] 339 UDP traffic over Tor [ACCEPTED] 340 Packed and fragmented relay messages [OPEN] 341 A better algorithm for out-of-sockets eviction [OPEN] 342 Decoupling hs_interval and SRV lifetime [DRAFT] 343 CAA Extensions for the Tor Rendezvous Specification [OPEN] +344 Prioritizing Protocol Information Leaks in Tor [OPEN] +345 Migrating the tor specifications to mdbook [OPEN] Proposals by status: @@ -271,7 +273,6 @@ Proposals by status: DRAFT: 294 TLS 1.3 Migration 316 FlashFlow: A Secure Speed Test for Tor (Parent Proposal) - 327 A First Take at PoW Over Introduction Circuits 331 Res tokens: Anonymous Credentials for Onion Service DoS Resilience 342 Decoupling hs_interval and SRV lifetime NEEDS-REVISION: @@ -281,52 +282,49 @@ Proposals by status: 248 Remove all RSA identity keys 269 Transitionally secure hybrid handshakes 279 A Name System API for Tor Onion Services - 291 The move to two guard nodes 317 Improve security aspects of DNS name resolution - 329 Overcoming Tor's Bottlenecks with Traffic Splitting OPEN: 239 Consensus Hash Chaining 240 Early signing key revocation for directory authorities + 265 Load Balancing with Overhead Parameters [for arti-dirauth] 267 Tor Consensus Transparency 277 Detect multiple relay instances running with same ID [for 0.3.??] 287 Reduce circuit lifetime without overloading the network 295 Using ADL for relay cryptography (solving the crypto-tagging attack) 303 When and how to remove support for protocol versions 306 A Tor Implementation of IPv6 Happy Eyeballs - 308 Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography 309 Optimistic SOCKS Data 322 Extending link specifiers to include the directory port 323 Specification for Walking Onions - 324 RTT-based Congestion Control for Tor 326 The "tor-relay" Well-Known Resource Identifier 330 Modernizing authority contact entries 340 Packed and fragmented relay messages 341 A better algorithm for out-of-sockets eviction 343 CAA Extensions for the Tor Rendezvous Specification + 344 Prioritizing Protocol Information Leaks in Tor + 345 Migrating the tor specifications to mdbook ACCEPTED: - 265 Load Balancing with Overhead Parameters [for 0.2.9.x] - 282 Remove "Named" and "Unnamed" handling from consensus voting [for 0.3.3.x] - 285 Directory documents should be standardized as UTF-8 + 282 Remove "Named" and "Unnamed" handling from consensus voting [for arti-dirauth] + 285 Directory documents should be standardized as UTF-8 [for arti-dirauth] 292 Mesh-based vanguards 311 Tor Relay IPv6 Reachability 312 Tor Relay Automatic IPv6 Address Discovery 313 Tor Relay IPv6 Statistics 321 Better performance and usability for the MyFamily option (v2) - 336 Randomized schedule for guard retries - 337 A simpler way to decide, "Is this guard usable?" 338 Use an 8-byte timestamp in NETINFO cells 339 UDP traffic over Tor META: 000 Index of Tor Proposals 001 The Tor Proposal Process - 098 Proposals that should be written - 099 Miscellaneous proposals 202 Two improved relay encryption protocols for Tor cells 257 Refactoring authorities and making them more isolated from the net 290 Continuously update consensus methods FINISHED: 260 Rendezvous Single Onion Services [in 0.2.9.3-alpha] - 332 Ntor protocol with extra data, version 3 + 291 The move to two guard nodes + 324 RTT-based Congestion Control for Tor + 327 A First Take at PoW Over Introduction Circuits + 329 Overcoming Tor's Bottlenecks with Traffic Splitting 333 Vanguards lite [in 0.4.7.1-alpha] CLOSED: 101 Voting on the Tor Directory System [in 0.2.0.x] @@ -431,7 +429,10 @@ Proposals by status: 315 Updating the list of fields required in directory documents [in 0.4.5.1-alpha] 318 Limit protover values to 0-63 [in 0.4.5.1-alpha] 328 Make Relays Report When They Are Overloaded + 332 Ntor protocol with extra data, version 3 335 An authority-only design for MiddleOnly [in 0.4.7.2-alpha] + 336 Randomized schedule for guard retries + 337 A simpler way to decide, "Is this guard usable?" SUPERSEDED: 112 Bring Back Pathlen Coin Weight 113 Simplifying directory authority administration @@ -458,6 +459,7 @@ Proposals by status: 266 Removing current obsolete clients from the Tor network 280 Privacy-Preserving Statistics with Privcount in Tor 299 Preferring IPv4 or IPv6 based on IP Version Failure Count + 308 Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography 334 A Directory Authority Flag To Mark Relays As Middle-only DEAD: 100 Tor Unreliable Datagram Extension Proposal @@ -486,6 +488,8 @@ Proposals by status: 286 Controller APIs for hibernation access on mobile 320 Removing TAP usage from v2 onion services OBSOLETE: + 098 Proposals that should be written + 099 Miscellaneous proposals 127 Relaying dirport requests to Tor download site / website 131 Help users to verify they are using Tor 132 A Tor Web Service For Verifying Correct Browser Configuration diff --git a/proposals/098-todo.txt b/proposals/098-todo.txt index a0bbbeb..0acb464 100644 --- a/proposals/098-todo.txt +++ b/proposals/098-todo.txt @@ -2,7 +2,9 @@ Filename: 098-todo.txt Title: Proposals that should be written Author: Nick Mathewson, Roger Dingledine Created: 26-Jan-2007 -Status: Meta +Status: Obsolete + +{Obsolete: This document has been replaced by the tor-spec issue tracker.} Overview: diff --git a/proposals/099-misc.txt b/proposals/099-misc.txt index a3621dd..ef34c80 100644 --- a/proposals/099-misc.txt +++ b/proposals/099-misc.txt @@ -2,7 +2,10 @@ Filename: 099-misc.txt Title: Miscellaneous proposals Author: Various Created: 26-Jan-2007 -Status: Meta +Status: Obsolete + +{This document is obsolete; we only used it once, and we have implemented +its only idea.) Overview: diff --git a/proposals/265-load-balancing-with-overhead.txt b/proposals/265-load-balancing-with-overhead.txt index e79d0a1..731a5b0 100644 --- a/proposals/265-load-balancing-with-overhead.txt +++ b/proposals/265-load-balancing-with-overhead.txt @@ -2,8 +2,31 @@ Filename: 265-load-balancing-with-overhead.txt Title: Load Balancing with Overhead Parameters Authors: Mike Perry Created: 01 January 2016 -Status: Accepted -Target: 0.2.9.x +Status: Open +Target: arti-dirauth + +NOTE: This is one way to address several load balancing problems in Tor, +including padding overhead and Exit+Guard issues. However, before attempting +this, we should see if we can simplify the equations further by changing how +we assign Guard, Fast and Stable flags in the first place. If we assign Guard +flags such that Guards are properly allocated wrt Middle and Fast, and avoid +assigning Guard to Exit, this will become simpler. Unfortunately, this is +literally impossible to fix with C-Tor. In adition to numerous overrides and +disparate safety checks that prevent changes, several bugs mean that Guard, +Stable, and Fast flags are randomly assigned: See: + https://gitlab.torproject.org/tpo/core/tor/-/issues/40230 + https://gitlab.torproject.org/tpo/core/tor/-/issues/40395 + https://gitlab.torproject.org/tpo/core/tor/-/issues/19162 + https://gitlab.torproject.org/tpo/core/tor/-/issues/40733 + https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/45 + https://gitlab.torproject.org/tpo/core/torspec/-/issues/100 + https://gitlab.torproject.org/tpo/core/torspec/-/issues/160 + https://gitlab.torproject.org/tpo/core/torspec/-/issues/158 + +Other approaches to flag equations that have been proposed: + https://github.com/frochet/wf_proposal/blob/master/waterfilling-balancing-with-max-diversity.txt + https://petsymposium.org/popets/2023/popets-2023-0127.pdf + 0. Motivation diff --git a/proposals/282-remove-named-from-consensus.txt b/proposals/282-remove-named-from-consensus.txt index 7fc28f0..eeef519 100644 --- a/proposals/282-remove-named-from-consensus.txt +++ b/proposals/282-remove-named-from-consensus.txt @@ -3,7 +3,7 @@ Title: Remove "Named" and "Unnamed" handling from consensus voting Author: Nick Mathewson Created: 12-Sep-2017 Status: Accepted -Target: 0.3.3.x +Target: arti-dirauth 1. Summary diff --git a/proposals/285-utf-8.txt b/proposals/285-utf-8.txt index c393e46..cb7bab4 100644 --- a/proposals/285-utf-8.txt +++ b/proposals/285-utf-8.txt @@ -3,6 +3,8 @@ Title: Directory documents should be standardized as UTF-8 Author: Nick Mathewson Created: 13 November 2017 Status: Accepted +Target: arti-dirauth +Ticket: https://gitlab.torproject.org/tpo/core/tor/-/issues/40131 1. Summary and motivation diff --git a/proposals/291-two-guard-nodes.txt b/proposals/291-two-guard-nodes.txt index a9554c6..56424cc 100644 --- a/proposals/291-two-guard-nodes.txt +++ b/proposals/291-two-guard-nodes.txt @@ -3,7 +3,7 @@ Title: The move to two guard nodes Author: Mike Perry Created: 2018-03-22 Supersedes: Proposal 236 -Status: Needs-Revision +Status: Finished 0. Background diff --git a/proposals/308-counter-galois-onion.txt b/proposals/308-counter-galois-onion.txt index e1f48bc..a57a38e 100644 --- a/proposals/308-counter-galois-onion.txt +++ b/proposals/308-counter-galois-onion.txt @@ -3,9 +3,17 @@ Title: Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptograph Authors: Jean Paul Degabriele, Alessandro Melloni, Martijn Stam Created: 13 Sep 2019 Last-Modified: 13 Sep 2019 -Status: Open +Status: Superseded + NOTE: This proposal is superseded by an improved version of the + Counter Galois Onion design based on the authors' forthcoming + paper, "Counter Galois Onion: Fast, Forward-Secure, and + Non-Malleable Onion Encryption for Tor". The improved proposal + will be publicly available once the paper is closer to being + ready for publication. + -nickm + 1. Background and Motivation diff --git a/proposals/324-rtt-congestion-control.txt b/proposals/324-rtt-congestion-control.txt index 582c54d..4235be8 100644 --- a/proposals/324-rtt-congestion-control.txt +++ b/proposals/324-rtt-congestion-control.txt @@ -2,7 +2,7 @@ Filename: 324-rtt-congestion-control.txt Title: RTT-based Congestion Control for Tor Author: Mike Perry Created: 02 July 2020 -Status: Open +Status: Finished 0. Motivation [MOTIVATION] @@ -2148,7 +2148,7 @@ The client MUST reject an ntorv3 reply with field EXT_FIELD_TYPE=02, if the client did not include EXT_FIELD_TYPE=01 in its handshake. The client SHOULD reject a sendme_inc field value that differs from the -current 'cc_sendme_inc' consensus parameter by more than a factor of 2, in +current 'cc_sendme_inc' consensus parameter by more than +/- 1, in either direction. If a client rejects a handshake, it MUST close the circuit. @@ -2159,8 +2159,7 @@ The pedantic reader will note that a rogue consensus can cause all clients to decide to close circuits by changing 'cc_sendme_inc' by a large margin. As a matter of policy, the directory authorities MUST NOT change -'cc_sendme_inc' by more than a factor of two (2), within a four (4) hour -window, for this reason. +'cc_sendme_inc' by more than +/- 1. In Shadow simulation, the optimal 'cc_sendme_inc' value to be ~31 cells, or one (1) TLS record worth of cells. We do not expect to change this value diff --git a/proposals/327-pow-over-intro.txt b/proposals/327-pow-over-intro.txt index 3765b8b..bcaf6f3 100644 --- a/proposals/327-pow-over-intro.txt +++ b/proposals/327-pow-over-intro.txt @@ -2,7 +2,7 @@ Filename: 327-pow-over-intro.txt Title: A First Take at PoW Over Introduction Circuits Author: George Kadianakis, Mike Perry, David Goulet, tevador Created: 2 April 2020 -Status: Draft +Status: Finished 0. Abstract @@ -167,11 +167,11 @@ Status: Draft 1) At the lowest layers, blake2b and siphash are used as hashing and PRNG algorithms that are well suited to common 64-bit CPUs. - 2) A custom hash function, HashX, uses dynamically generated functions that - are tuned to be a good match for pipelined integer and floating point - performance on current 64-bit CPUs. This layer provides the strongest ASIC - resistance, since a reimplementation in hardware would need to implement - much of a CPU to compute these functions efficiently. + 2) A custom hash function family, HashX, randomizes its implementation for + each new seed value. These functions are tuned to utilize the pipelined + integer performance on a modern 64-bit CPU. This layer provides the + strongest ASIC resistance, since a hardware reimplementation would need + to include a CPU-like pipelined execution unit to keep up. 3) The Equi-X layer itself builds on HashX and adds an algorithmic puzzle that's designed to be strongly asymmetric and to require RAM to solve efficiently. diff --git a/proposals/329-traffic-splitting.txt b/proposals/329-traffic-splitting.txt index 93655f0..2a24f1f 100644 --- a/proposals/329-traffic-splitting.txt +++ b/proposals/329-traffic-splitting.txt @@ -2,7 +2,7 @@ Filename: 329-traffic-splitting.txt Title: Overcoming Tor's Bottlenecks with Traffic Splitting Author: David Goulet, Mike Perry Created: 2020-11-25 -Status: Needs-Revision +Status: Finished 0. Status diff --git a/proposals/332-ntor-v3-with-extra-data.md b/proposals/332-ntor-v3-with-extra-data.md index b76a451..58a3bf3 100644 --- a/proposals/332-ntor-v3-with-extra-data.md +++ b/proposals/332-ntor-v3-with-extra-data.md @@ -3,7 +3,7 @@ Filename: 332-ntor-v3-with-extra-data.md Title: Ntor protocol with extra data, version 3. Author: Nick Mathewson Created: 12 July 2021 -Status: Finished +Status: Closed ``` # Overview diff --git a/proposals/336-randomize-guard-retries.md b/proposals/336-randomize-guard-retries.md index 05cf1c3..0e819d4 100644 --- a/proposals/336-randomize-guard-retries.md +++ b/proposals/336-randomize-guard-retries.md @@ -3,9 +3,15 @@ Filename: 336-randomize-guard-retries.md Title: Randomized schedule for guard retries Author: Nick Mathewson Created: 2021-10-22 -Status: Accepted +Status: Closed ``` +# Implementation Status + +> This proposal is implemented in Arti, and recommended for future +> guard implementations. We have no current plans to implement it in +> C Tor. + # Introduction When we notice that a guard isn't working, we don't mark it as retriable diff --git a/proposals/337-simpler-guard-usability.md b/proposals/337-simpler-guard-usability.md index 898c6e0..a2f93f7 100644 --- a/proposals/337-simpler-guard-usability.md +++ b/proposals/337-simpler-guard-usability.md @@ -3,7 +3,7 @@ Filename: 337-simpler-guard-usability.md Title: A simpler way to decide, "Is this guard usable?" Author: Nick Mathewson Created: 2021-10-22 -Status: Accepted +Status: Closed ``` # Introduction diff --git a/proposals/344-protocol-info-leaks.txt b/proposals/344-protocol-info-leaks.txt new file mode 100644 index 0000000..abae2a7 --- /dev/null +++ b/proposals/344-protocol-info-leaks.txt @@ -0,0 +1,1186 @@ +Filename: 344-protocol-info-leaks.txt +Title: Prioritizing Protocol Information Leaks in Tor +Author: Mike Perry +Created: 2023-07-17 +Purpose: Normative +Status: Open + + +0. Introduction + +Tor's protocol has numerous forms of information leaks, ranging from highly +severe covert channels, to behavioral issues that have been useful +in performing other attacks, to traffic analysis concerns. + +Historically, we have had difficulty determining the severity of these +information leaks when they are considered in isolation. At a high level, many +information leaks look similar, and all seem to be forms of traffic analysis, +which is regarded as a difficult attack to perform due to Tor's distributed +trust properties. + +However, some information leaks are indeed more severe than others: some can +be used to remove Tor's distributed trust properties by providing a covert +channel and using it to ensure that only colluding and communicating relays +are present in a path, thus deanonymizing users. Some do not provide this +capability, but can be combined with other info leak vectors to quickly yield +Guard Discovery, and some only become dangerous once Guard Discovery or other +anonymity set reduction is already achieved. + +By prioritizing information leak vectors by their co-factors, impact, and +resulting consequences, we can see that these attack vectors are not all +equivalent. Each vector of information leak also has a common solution, and +some categories even share the same solution as other categories. + +This framework is essential for understanding the context in which we will be +addressing information leaks, so that decisions and fixes can be understood +properly. This framework is also essential for recognizing when new protocol +changes might introduce information leaks or not, for gauging the severity of +such information leaks, and for knowing what to do about them. + +Hence, we are including it in tor-spec, as a living, normative document to be +updated with experience, and as external research progresses. + +It is essential reading material for any developers working on new Tor +implementations, be they Arti, Arti-relay, or a third party implementation. + +This document is likely also useful to developers of Tor-like anonymity +systems, of which there are now several, such as I2P, MASQUE, and Oxen. They +definitely share at least some, and possibly even many of these issues. + +Readers who are relatively new to anonymity literature may wish to first +consult the Glossary in Section 3, especially if terms such as Covert Channel, +Path Bias, Guard Discovery, and False Positive/False Negative are unfamiliar +or hazy. There is also a catalog of historical real-world attacks that are +known to have been performed against Tor in Section 2, to help illustrate how +information leaks have been used adversarially, in practice. + +We are interested in hearing from journalists and legal organizations who +learn about court proceedings involving Tor. We became aware of three +instances of real-world attacks covered in Section 2 in this way. Parallel +construction (hiding the true source of evidence by inventing an alternate +story for the court -- also known as lying) is a possibility in the US and +elsewhere, but (so far) we are not aware of any direct evidence of this +occurring with respect to Tor cases. Still, keep your eyes peeled... + + +0.1. Table of Contents + + 1. Info Leak Vectors + 1.1. Highly Severe Covert Channel Vectors + 1.1.1. Cryptographic Tagging + 1.1.2. End-to-end cell header manipulation + 1.1.3. Dropped cells + 1.2. Info Leaks that enable other attacks + 1.2.1. Handshakes with unique traffic patterns + 1.2.2. Adversary-Induced Circuit Creation + 1.2.3. Relay Bandwidth Lying + 1.2.4. Metrics Leakage + 1.2.5. Protocol Oracles + 1.3. Info Leaks of Research Concern + 1.3.1. Netflow Activity + 1.3.2. Active Traffic Manipulation Covert Channels + 1.3.3. Passive Application-Layer Traffic Patterns + 1.3.4. Protocol or Application Linkability + 1.3.5. Latency Measurement + 2. Attack Examples + 2.1. CMU Tagging Attack + 2.2. Guard Discovery Attacks with Netflow Deanonymization + 2.3. Netflow Anonymity Set Reduction + 2.4. Application Layer Confirmation + 3. Glossary + + +1. Info Leak Vectors + +In this section, we enumerate the vectors of protocol-based information leak +in Tor, in order of highest priority first. We separate these vectors into +three categories: "Highly Severe Covert Channels", "Info Leaks that Enable +other attacks", and "Info Leaks Of Research Concern". The first category +yields deanonymization attacks on their own. The second category enables other +attacks that can lead to deanonymization. The final category can be aided by +the earlier vectors to become more severe, but overall severity is a +combination of many factors, and requires further research to illuminate all +of these factors. + +For each vector, we provide a brief "at-a-glance" summary, which includes a +ballpark estimate of Accuracy in terms of False Positives (FP) and False +Negatives (FN), as 0, near-zero, low, medium, or high. We then list what is +required to make use of the info leak, the impact, the reason for the +prioritization, and some details on where the signal is injected and observed. + + +1.1. Highly Severe Covert Channel Vectors + +This category of info leak consists entirely of covert channel vectors that +have zero or near-zero false positive and false negative rates, because they +can inject a covert channel in places where similar activity would not happen, +and they are end-to-end. + +They also either provide or enable path bias attacks that can capture +the route clients use, to ensure that only malicious exits are used, leading +to full deanonymization when the requirements are met. + +If the adversary has censorship capability, and can ensure that users only +connect to compromised Guards (or Bridges), they can fully deanonymize all +users with these covert channels. + + +1.1.1. Cryptographic Tagging + +At a glance: + Accuracy: FP=0, FN=0 + Requires: Malicious or compromised Guard, at least one exit + Impact: Full deanonymization (path bias, identifier transmission) + Path Bias: Automatic route capture (all non-deanonymized circuits fail) + Reason for prioritization: Severity of Impact; similar attacks used in wild + Signal is: Modified cell contents + Signal is injected: by guard + Signal is observed: by exit + +First reported at Black Hat in 2009 (see [ONECELL]), and elaborated further +with the path bias amplification attack in 2012 by some Raccoons (see +[RACCOON23]), this is the most severe vector of covert channel attack in Tor. + +Cryptographic tagging is where an adversary who controls a Guard (or Bridge) +XORs an identifier, such as an IP address, directly into the circuit's +cipher-stream, in an area of known-plaintext. This tag can be exactly +recovered by a colluding exit relay, ensuring zero false positives and zero +false negatives for this built-in identifier transmission, along with their +collusion signal. + +Additionally, because every circuit that does not have a colluding relay will +automatically fail because of the failed digest validation, the adversary gets +a free path bias amplification attack, such that their relay only actually +carries traffic that they know they have successfully deanonymized. Because +clients will continually attempt to re-build such circuits through the guard +until they hit a compromised exit and succeed, this violates Tor's distributed +trust assumption, reducing it to the same security level as a one-hop proxy +(ie: the security of fully trusting the Guard relay). Worse still, when the +adversary has full censorship control over all connections into the Tor +network, Tor provides zero anonymity or privacy against them, when they also +use this vector. + +Because the Exit is able to close *all* circuits that are not deanonymized, +for maximal efficiency, the adversary's Guard capacity should exactly match +their Exit capacity. To make up for the loss of traffic caused by closing many +circuits, relays can lie about their bandwidth (see Section 1.2.3). + +Large amounts of circuit failure (that might be evidence of such an attack) +are tracked and reported by C-Tor in the logs, by the path bias detector, but +when the Guard is under DDoS, or even heavy load, this can yield false alarms. +These false alarms happened frequently during the network-wide DDoS of +2022-2023. They can also be induced at arbitrary Guards via DoS, to make users +suspicious of their Guards for no reason. + +The path bias detector could have a second layer in Arti, that checks to see +if any specific Exits are overused when the circuit failure rate is high. This +would be more indicative of an attack, but could still go off if the user is +actually trying to use rare exits (ie: country selection, bittorrent). + +This attack, and path bias attacks that are used in the next two sections, do +have some minor engineering barriers when being performed against both onion +and exit traffic, because the onion service traffic is restricted to +particular hops in the case of HSDIR and intro point circuits. However, +because pre-built circuits are used to access HSDIR and intro points, the +adversary can use their covert channel such that only exits and pre-built +onion service circuits are allowed to proceed. Onion services are harder to +deanonymize in this way, because the HSDIR choice itself can't be controlled +by them, but they can still be connected to using pre-built circuits until the +adversary also ends up in the HSDIR position, for deanonymization. + +Solution: Path Bias Exit Usage Counter; + Counter Galois Onion (CGO) (Forthcoming update to Prop#308). +Status: Unfixed (Current PathBias detector is error-prone under DDoS) +Funding: CGO explicitly funded via Sponsor 112 + + +1.1.2. End-to-end cell header manipulation + +At a glance: + Accuracy: FP=0, FN=0 + Requires: Malicious or compromised Guard, at least one exit + Impact: Full deanonymization (path bias, identifier transmission) + Path Bias: Full route capture is trivial + Reason for prioritization: Severity of Impact; used in the wild + Signal is: Modified cell commands. + Signal is injected: By either guard or exit/HSDIR + Signal is observed: By either guard or exit/HSDIR + +The Tor protocol consists of both cell header commands, and relay header +commands. Cell commands are not encrypted by circuit-level encryption, so they +are visible and modifiable by every relay in the path. Relay header commands +are encrypted, and not visible to every hop in the path. + +Not all cell commands are forwarded end-to-end. Currently, these are limited +to RELAY, RELAY_EARLY, and DESTROY. Because of the attack described here, +great care must be taken when adding new end-to-end cell commands, even if +they are protected by a MAC. + +Previously, a group of researchers at CMU used this property to modify the +cell command header of cells on circuits, to switch between RELAY_EARLY and +RELAY at exits and HSDIRs (see [RELAY_EARLY]). This creates a visible bit in +each cell, that can signal collusion, or with enough cells, can encode an +identifier such as an IP address. They assisted the FBI, to use this attack in +the wild to deanonymize clients. + +We addressed the CMU attack by closing the circuit upon receiving an "inbound" +(towards the client) RELAY_EARLY command cell, and by limiting the number of +"outbound" (towards the exit) RELAY_EARLY command cells at relays, and by +requiring the use of RELAY_EARLY for EXTEND (onionskin) relay commands. This +defense is not generalized, though. Guards may still use this specific covert +channel to send around 3-5 bits of information after the extend handshake, +without killing the circuit. It is possible to use the remaining outbound +vector to assist in path bias attacks for dropped cells, as a collusion signal +to reduce the amount of non-compromised traffic that malicious exits must +carry (see the following Section 1.1.3). + +If this covert channel is not addressed, it is trivial for a Guard and Exit +relays to close every circuit that does not display this covert channel, +providing path bias amplification attack and distributed trust reduction, +similar to cryptographic tagging attacks. Because the inbound direction *is* +addressed, we believe this kind of path bias is currently not possible with +this vector by itself (thus also requiring the vector from Section 1.1.3), but +it could easily become possible if this defense is forgotten, or if a new +end-to-end cell type is introduced. + +While more cumbersome than cryptographic tagging attacks, in practice this +attack is just as successful, if these cell command types are not restricted +and limited. It is somewhat surprising that the FBI used this attack before +cryptographic tagging, but perhaps that was just a lucky coincidence of +opportunity. + +Solution: CGO (Updated version of Prop#308) covers cell commands in the MAC; + Any future end-to-end cell commands must still limit usage +Status: Fix specific to CMU attack; Outbound direction is unfixed +Funding: Arti and relay-side fixes are explicitly funded via Sponsor 112 + + +1.1.3. Dropped cells + +At a glance: + Accuracy: FP=0, FN=0 + Requires: Malicious Guard or Netflow data (if high volume), one exit + Impact: Full deanonymization (path bias amplification, collusion signal) + Path Bias: Full route capture is trivial + Reason for prioritization: Severity of Impact; similar attacks used in wild + Signal is: Unusual patterns in number of cells received + Signal is injected: By exit or HSDIR + Signal is observed: at guard or client<->guard connection. + +Dropped cells are cells that a relay can inject that end up ignored and +discarded by a Tor client. These include: + - Unparsable cells + - Unrecognized cells (ie: wrong source hop, or decrypt failures) + - invalid relay commands + - unsupported (or consensus-disabled) relay commands or extensions + - out-of-context relay commands + - duplicate relay commands + - relay commands that hit any error codepaths + - relay commands for an invalid or already-closed stream ID + - semantically void relay cells (incl relay data len == 0, or PING) + - onion descriptor-appended junk + +This attack works by injecting inbound RELAY cells at the exit or at a middle +relay, and then observing anomalous traffic patterns at the guard or at the +client->guard connection. + +The severity of this covert channel is extreme (zero false positives; zero +false negatives) when they are injected in cases where the circuit is +otherwise known to be silent, because of the protocol state machine. These +cases include: + - Immediately following an onionskin response + - During other protocol handshakes (onion services, conflux) + - Following relay CONNECTED or RESOLVED (not as severe - no path bias) + +Because of the stateful and deterministic nature of the Tor protocol, +especially handshakes, it is easy to accurately recognize these specific cases +even when observing only encrypted circuit traffic at the Guard relay (see +[DROPMARK]). + +Because this covert channel is most accurate before actual circuit use, when +the circuit is expected to be otherwise silent, it is trivial for a Guard +relay to close every circuit that does not display this covert channel, +providing path bias amplification attack and distributed trust reduction, +similar to cryptographic tagging attacks and end-to-end cell header +manipulation. This ability to use the collusion signal to perform path bias +before circuit use differentiates dropped cells within the Tor Protocol from +deadweight traffic during application usage (such as javascript requests for +404 URLs, covered in Section 1.3.2). + +This category is not quite as severe as these previous two categories by +itself, for two main reasons. However, it is also the case that due to other +factors, these reasons may not matter in practice. + +First, the Exit can't use this covert channel to close circuits that are not +deanonymized by a colluding Guard, since there is no covert channel from the +Guard to the Exit with this vector alone. Thus, unlike cryptographic tagging, +the adversary's Exits will still carry non-deanonymized traffic from +non-adversary Guards, and thus the adversary needs more Exit capacity than +Guard capacity. These kinds of more subtle trade-offs with respect to path +bias are covered in [DOSSECURITY]. However, note that this issue can be fixed +by using the previous RELAY_EARLY covert channel from the Guard to the Exit +(since this direction is unfixed). This allows the adversary to confirm +receipt of the dropped cell covert channel, allowing both the Guard and the +Exit to close all non-confirmed circuits, and thus ensure that they only need +to allocate equal amounts of compromised Guard and Exit traffic, to monitor +all Tor traffic. + +Second, encoding a full unique identifier in this covert channel is +non-trivial. A significant amount of injected traffic must be sent to exchange +more than a simple collusion signal, to link circuits when attacking a large +number of users. In practice, this likely means some amount of correlation, +and a resulting (but very small) statistical error. + +Obviously, the actual practical consequences of these two limitations are +questionable, so this covert channel is still regarded as "Highly Severe". It +can still result in full deanonymization of all Tor traffic by an adversary +with censorship capability, with very little error. + +Solution: Forthcoming dropped-cell proposal +Status: Fixed with vanguards addon; Unfixed otherwise +Funding: Arti and relay-side fixes are explicitly funded via Sponsor 112 + + +1.2. Info Leaks that enable other attacks + +These info leaks are less severe than the first group, as they do not yield +full covert channels, but they do enable other attacks, including guard +discovery and eventual netflow deanonymization, and website traffic +fingerprinting. + + +1.2.1. Handshakes with unique traffic patterns + +At a glance: + Accuracy: FP=near-zero, FN=near-zero + Requires: Compromised Guard + Impact: Anonymity Set Reduction and Oracle; assists in Guard Discovery + Path Bias: Full route capture is difficult (high failure rate) + Reason for Prioritization: Increases severity of vectors 1.2.2 and 1.3.3 + Signal is: Caused by client's behavior. + Signal is observed: At guard + Signal is: Unique cell patterns + +Certain aspects of Tor's handshakes are very unique and easy to fingerprint, +based only on observed traffic timing and volume patterns. In particular, the +onion client and onion service handshake activity is fingerprintable with +near-zero false negatives and near-zero false positive rates, as per +[ONIONPRINT]. The conflux link handshake is also unique (and thus accurately +recognizable), because it is our only 3-way handshake. + +This info leak is very accurate. However, the impact is much lower than that +of covert channels, because by itself, it can only tell if a particular Tor +protocol, behavior, or feature is in use. + +Additionally, Tor's distributed trust properties remain in-tact, because there +is no collusion signal built in to this info leak. When a path bias attack +is mounted to close circuits during circuit handshake construction without a +collusion signal to the Exit, it must proceed hop-by-hop. Guards must close +circuits that do not extend to colluding middles, and those colluding middles +must close circuits that don't extend to colluding exits. This means that the +adversary must control some relays in each position, and has a substantially +higher circuit failure rate while directing circuits to each of these relays +in a path. + +To put this into perspective, an adversary using a collusion signal with 10% +of Exits expects to fail 9 circuits before detecting their signal at a +colluding exit and allowing a circuit to succeed. However, an adversary +without a collusion signal and 10% of all relays expects to fail 9 circuits +before getting a circuit to their middle, but then expects 9 of *those* +circuits to fail before reaching an Exit, for 81 circuit failures for every +successful circuit. + +Published attacks have built upon this info leak, though. + +In particular, certain error conditions, such as returning a single +"404"-containing relay cell for an unknown onion service descriptor, are +uniquely recognizable. This fingerprint was used in the [ONIONFOUND] guard +discovery attack, and they provide a measurement of its uniqueness. + +Additionally, onion client fingerprintability can be used to vastly reduce the +set of website traffic traces that need to be considered for website traffic +fingerprinting (see Section 1.3.3), making that attack realistic and +practical. Effectively, it functions as a kind of oracle in this case (see +Glossary, and [ORACLES]). + +Solution: Padding machines at middles for protocol handshakes (as per [PCP]); + Pathbias-lite. +Status: Padding machines deployed for onion clients, but have weaknesses + against DF and stateful cross-circuit fingerprints +Funding: Not explicitly funded + + +1.2.2. Adversary-Induced Circuit Creation + +At a glance: + Accuracy: FP=high, FN=high + Requires: Onion service activity, or malicious exit + Impact: Guard discovery + Path Bias: Repeated circuits eventually provide the desired path + Reason for Prioritization: Enables Guard Discovery + Signal is: Inducing a client to make a new Tor circuit + Signal is injected: by application layer, client, or malicious relay + Signal is observed: At middle + +By itself, the ability for an adversary to cause a client to create circuits +is not a covert channel or arguably even an info leak. Circuit creation, even +bursts of frequent circuit creation, is commonplace on the Tor network. + +However, when this activity is combined with a covert channel from Section +1.1, with a unique handshake from Section 1.2.1, or with active traffic +manipulation (Section 1.3.2), then it leads to Guard Discovery, by allowing +the adversary to recognize when they are chosen for the Middle position, and +thus learn the Guard. Once Guard Discovery is achieved, netflow analysis of +the Guard's connections can be used to perform intersection attacks and +eventually determine the client IP address (see Section 1.3.1). + +Large quantities of circuit creation can be induced by: + - Many connections to an Onion Service + - Causing a client to make connections to many onion service addresses + - Application connection to ports in rare exit policies, followed by circuit + close at Exit + - Repeated Conflux leg failures + +In Tor 0.4.7 and later, onion services are protected from this activity via +Vanguards-Lite (Proposal #333). This system adds a second layer of vanguards +to onion service circuits, with rotation times set such that it is sufficient +to protect a user for use cases on the order of weeks, assuming the adversary +does not get lucky and land in a set. Non-Onion service activity, such as +Conflux leg failures, is protected by feature-specific rate limits. + +Longer lived onion services should use the Vanguards Addon, which implements +Mesh Vanguards (Prop#292). It uses two layers of vanguards, and expected +use cases of months. + +These attack times are probabilistic expectations, and are rough estimates. +See the proposals for details. To derive these numbers, the proposals assume a +100% accurate covert channel for detecting that the middle is in the desired +circuit. If we address the low hanging fruit for such covert channels above, +these numbers change, and such attacks also become much more easily +detectable, as they will rely on application layer covert channels (See +Section 1.3.2), which will resemble an application layer DoS or flood. + +Solution: Mesh-vanguards (Prop#292); Vanguards-lite (Prop#333); rate limiting + circuit creation attempts; rate limiting the total number of distinct + paths used by circuits +Status: Vanguards-lite deployed in Tor 0.4.7; Mesh-vanguards is vanguards addon; + Conflux leg failures are limited per-exit; Exitpolicy scanner exists +Funding: Not explicitly funded + + +1.2.3. Relay Bandwidth Lying + +At a glance: + Accuracy: FP=high, FN=high + Requires: Running relays in the network + Impact: Additional traffic towards malicious relays + Path Bias: Bandwidth lying can make up for circuit rejection + Reason for prioritization: Assists Covert Channel Path Bias attacks + Signal is injected: by manipulating reported descriptor bandwidths + Signal is observed: by clients choosing lying relays more often + Signal is: the effect of using lying relays more often + +Tor clients select relays for circuits in proportion to their fraction of +consensus "bandwidth" weight. This consensus weight is calculated by +multiplying the relay's self-reported "observed" descriptor bandwidth value by +a ratio that is measured by the Tor load balancing system (formerly TorFlow; +now sbws -- see [SBWS] for an overview). + +The load balancing system uses two-hop paths to measure the stream bandwidth +through all relays on the network. The ratio is computed by determining a +network-wide average stream bandwidth, 'avg_sbw', and a per-relay average +stream bandwidth, 'relay_sbw'. Each relay's ratio value is 'relay_sbw/avg_sbw'. +(There are also additional filtering steps to remove slow outlier streams). + +Because the consensus weights for relays derive from manipulated descriptor +values by multiplication with this ratio, relays can still influence their +weight by egregiously lying in their descriptor value, thus attracting more +client usage. They can also attempt to fingerprint load balancer activity and +selectively give it better service, though this is more complicated than +simply patching Tor to lie. + +This attack vector is especially useful when combined with a path bias attack +from Section 1.1: if an adversary is using one of those covert channels to +close a large portion of their circuits, they can make up for this loss of +usage by inflating their corresponding bandwidth value by an equivalent +amount, thus causing the load balancer to still measure a reasonable ratio for +them, and thus still provide fast service for the fully deanonymized circuits +that they do carry. + +There are many research papers written on alternate approaches to the +measurement problem. These have not been deployed for three reasons: + 1. The unwieldy complexity and fragility of the C-Tor codebase + 2. The conflation of measurement with load balancing (we need both) + 3. Difficulty performing measurement of the fastest relays with + non-detectable/distributed mechanisms + +In the medium term, we will work on detecting bandwidth lying and manipulation +via scanners. In the long term, Arti-relay will allow the implementation of +distributed and/or dedicated measurement components, such as [FLASHFLOW]. +(Note that FlashFlow still needs [SBWS] or another mechanism to handle load +balancing, though, since FlashFlow only provides measurement). + +Solutions: Scan for lying relays; implement research measurement solutions +Status: A sketch of the lying relay scanner design is in [LYING_SCANNER] +Funding: Scanning for lying relays is funded via Sponsor 112 + + +1.2.4. Metrics Leakage + +At a glance: + Accuracy: FP=low, FN=high + Requires: Some mechanism to bias or inflate reported relay metrics + Impact: Guard discovery + Path Bias: Potentially relevant, depending on type of leak + Reason for prioritization: Historically severe issues + Signal is injected: by interacting with onion service + Signal is observed: by reading router descriptors + Signal is: information about volume of traffic and number of IP addresses + +In the past, we have had issues with info leaks in our metrics reporting (see +[METRICSLEAK]). We addressed them by lowering the resolution of read/write +history, and ensuring certain error conditions could not willfully introduce +noticeable asymmetries. However, certain characteristics, like reporting local +onion or SOCKS activity in relay bandwidth counts, still remain. + +Additionally, during extremely large flooding or DDoS attempts, it may still +be possible to see the corresponding increases in reported metrics for Guards +in use by onion services, and thus discover its Guards. + +Solutions: Fix client traffic reporting; remove injectable asymmetries; + reduce metrics resolution; add noise +Status: Metrics resolution reduced to 24hr; known asymmetries fixed +Funding: Not funded + + +1.2.5. Protocol Oracles + +At a glance: + Accuracy: FP=medium, FN=0 (for unpopular sites: FP=0, FN=0) + Requires: Probing relay DNS cache + Impact: Assists Website Traffic Fingerprinting; Domain Usage Analytics + Path Bias: Not Possible + Reason for prioritization: Historically accurate oracles + Signal is injected: by client causing DNS caching at exit + Signal is observed: by probing DNS response wrt to cell ordering via all exits + Signal is: If cached, response is immediate; otherwise other cells come first + +Protocol oracles, such as exit DNS cache timing to determine if a domain has +been recently visited, increase the severity of Website Traffic Fingerprinting +in Section 1.3.3, by reducing false positives, especially for unpopular +websites. + +There are additional forms of oracles for Website Traffic Fingerprinting, but +the remainder are not protocol oracles in Tor. See [ORACLES] in the +references. + +Tor deployed a defense for this oracle in the [DNSORACLE] tickets, to +randomize expiry time. This helps reduce the precision of this oracle for +popular and moderately popular domains/websites in the network, but does not +fully eliminate it for unpopular domains/websites. + +The paper in [DNSORACLE] specifies a further defense, using a pre-load of +popular names and circuit cache isolation defense in Section 6.2, with third +party resolvers. The purpose of the pre-load list is to preserve the cache +hits for shared domains across circuits (~11-17% of cache hits, according to +the paper). The purpose of circuit isolation is to avoid Tor cache hits for +unpopular domains across circuits. The purpose of third party resolvers is to +ensure that the local resolver's cache does not become measurable, when +isolating non-preloaded domains to be per-circuit. + +Unfortunately, third party resolvers are unlikely to be recommended for use by +Tor, since cache misses of unpopular domains would hit them, and be subject to +sale in DNS analytics data at high resolution (see [NETFLOW_TICKET]). + +Also note that the cache probe attack can only be used by one adversary at a +time (or they begin to generate false positives for each other by actually +*causing* caching, or need to monitor for each other to avoid each other). +This is in stark contrast to third party resolvers, where this information is +sold and available to multiple adversaries concurrently, for all uncached +domains, with high resolution timing, without the need for careful +coordination by adversaries. + +However, note that an arti-relay implementation would no longer be single +threaded, and would be able to reprioritize asynchronous cache activity +arbitrarily, especially for sensitive uncached activity to a local resolver. +This might be useful for reducing the accuracy of the side channel, in this +case. + +Unfortunately, we lack sufficient clarity to determine if it is meaningful to +implement any further defense that does not involve third party resolvers +under either current C-Tor, or future arti-relay circumstances. + +Solutions: Isolate cache per circuit; provide a shared pre-warmed cache of + popular domains; smarter cache handling mechanisms? +Status: Randomized expiry only - not fully eliminated +Funding: Any further fixes are covered by Sponsor 112 + + +1.3. Info Leaks of Research Concern + +In this section, we list info leaks that either need further research, or are +undergoing active research. + +Some of these are still severe, but typically less so than the already covered +ones, unless they are part of a combined attack, such as with an Oracle, +or with Guard Discovery. + +Some of these may be more or less severe than currently suspected: If we +knew for certain, they wouldn't need research. + + +1.3.1. Netflow Activity + +At a glance: + Accuracy: FP=high; FN=0 (FN=medium with incomplete vantage point set) + Requires: Access to netflow data market, or ISP coercion + Impact: Anonymity Set Reduction; Deanonymization with Guard Discovery/Oracle + Path Bias: Not possible + Reason for Prioritization: Low impact without Guard Discovery/Oracle + Signal is: created by using the network + Signal is observed: at ISP of everything that is using the network. + Signal is: Connection tuple times and byte counts + +Netflow is a feature of internet routers that records connection tuples, as +well as time stamps and byte counts, for analysis. + +This data is bought and sold, by both governments and threat intelligence +companies, as documented in [NETFLOW_TICKET]. + +Tor has a padding mechanism to reduce the resolution of this data (see Section +2 of [PADDING_SPEC]), but this hinges on clients' ability to keep connections +open and padded for 45-60 minutes, even when idle. This padding reduces the +resolution of intersection attacks, making them operate on 30 minute time +windows, rather than 15 second time windows. This increases the false positive +rate, and thus increases the duration of such intersection attacks. + +Large scale Netflow data can also be used to track Tor users as they migrate +from location to location, without necessarily deanonymizing them. Because Tor +uses three directory guards, and has ~4000 Guard relays, the choice +Choose(4000,3) of directory Guards is ~10 billion different combinations, +though probability weighting of Guard selection does reduce this considerably +in practice. Lowering the total number of Guard relays (via arti-relay and +using only the fastest Guards), and using just two directory guards as opposed +to three can reduce this such that false positives become more common. More +thorough solutions are discussed in [GUARDSETS]. + +Location tracking aside, by itself, this data (especially when padded) is not +a threat to client anonymity. However, this data can also be used in +combination with a number of Oracles or confirmation vectors, such as: + - Guard Discovery + - Flooding an onion service with huge amounts of traffic in a pattern + - Advertising analytics or account activity log purchase + - TCP RST injection + - TLS conn rotation + +These oracles can be used to either confirm the connection of an onion +service, or to deanonymize it after Guard Discovery. + +In the case of clients, the use of Oracle data can enable intersection attacks +to deanonymize them. The oracle data necessary for client intersection attack +is also being bought and sold, as documented in [NETFLOW_TICKET]. It is +unknown how long such attacks take, but it is a function of the number of +users under consideration, and their connection durations. + +The research interest here is in determining what can be done to increase the +amount of time these attacks take, in terms of increasing connection duration, +increasing the number of users, reducing the total number of Guard relays, +using a UDP transport, or changing user behavior. + +Solutions: Netflow padding; connection duration increase; QUIC transport; + using bridges; decreasing total number of guards; using only two + directory guards; guardsets; limiting sensitive account usage +Status: Netflow padding deployed in C-Tor and arti +Funding: Not explicitly funded + + +1.3.2. Active Traffic Manipulation Covert Channels + +At a Glance: + Accuracy: FP=medium, FN=low + Requires: Netflow data, or compromised/monitored Guard + Impact: Anonymity Set Reduction; Netflow-assisted deanonymization + Path Bias: Possible via exit policy or onion service reconnection + Reason for Prioritization: Can assist other attacks; lower severity otherwise + Signal is injected: by the target application, manipulated by the other end. + Signal is observed: at Guard, or target->guard connection. + Signal is: Unusual traffic volume or timing. + +This category of covert channel occurs after a client has begun using a +circuit, by manipulating application data traffic. This manipulation can +occur either at the application layer, or at the Tor protocol layer. + +Because it occurs after the circuit is in use, it does not permit the use of +path bias or trust reduction properties by itself (unless combined with one of +the above info leak attack vectors -- most often Adversary-Induced Circuit +Creation). + +These covert channels also have a significantly higher false positive rate +than those before circuit use, since application traffic is ad-hoc and +arbitrary, and is also involved during the attempted manipulation of +application traffic. + +For onion services, this covert channel is much more severe: Onion services may +be flooded with application data in large-volume patterns over long periods of +time, which can be seen in netflow logs. + +For clients, this covert channel typically is only effective after the +adversary suspects an individual, for confirmation of their suspicion, or +after Guard Discovery. + +Examples of this class of covert channel include: + - Application-layer manipulation (AJAX) + - Traffic delays (rainbow, swirl - see [BACKLIT]) + - Onion Service flooding via HTTP POST + - Flooding Tor relays to notice traffic changes in onion service throughput + - Conflux leg switching patterns + - Traffic inflation (1 byte data cells) + +Solution: Protocol checks; Padding machines at middles for specific kinds of + traffic; limits on inbound onion service traffic; Backlit +Status: Protocol checks performed for conflux; vanguards addon closes + high-volume circuits +Funding: Not explicitly funded + + +1.3.3. Passive Application-Layer Traffic Patterns + +At a Glance: + Accuracy: FP=medium, FN=Medium + Requires: Compromised Guard (external monitoring increases FP+FN rate) + Impact: Links client and destination activity (ie: deanonymization with logs) + Path Bias: Not Possible + Reason for prioritization: Large FP rate without oracle, debated practicality + Signal is: not injected; passively extracted + Signal is observed: at Guard, or entire network + Signal is: timing and volume patterns of traffic. + +This category of information leak occurs after a client has begun using a +circuit, by analyzing application data traffic. + +Examples of this class of information leak include: + - Website traffic fingerprinting + - End-to-end correlation + +The canonical application of this information leak is in end-to-end +correlation, where application traffic entering the Tor network is correlated +to traffic exiting the Tor network (see [DEEPCOFFEA]). This attack vector +requires a global view of all Tor traffic, or false negatives skyrocket. +However, this information leak is also possible to exploit at a single +observation point, using machine learning classifiers (see [ROBFINGERPRINT]), +typically either the Guard or bridge relay, or the path between the +Guard/bridge and the client. + +In both cases, this information leak has a significant false positive rate, +since application traffic is ad-hoc, arbitrary, and self-similar. Because +multiple circuits are multiplexed on one TLS connection, the false positive +and false negative rates are higher still at this observation location, as +opposed to on a specific circuit. + +In both cases, the majority of the information gained by classifiers is in the +beginning of the trace (see [FRONT] and [DEEPCOFFEA]). + +This information leak gets more severe when it is combined with another oracle +(as per [ORACLES]) that can confirm the statistically derived activity, or +narrow the scope of material to analyze. Example oracles include: + - DNS cache timing + - Onion service handshake fingerprinting + - Restricting targeting to either specific users, or specific websites + - Advertising analytics or account activity log purchase (see + [NETFLOW_TICKET]) + +Website traffic fingerprinting literature is divided into two classes of +attack study: Open World and Closed World. Closed World is when the adversary +uses an Oracle to restrict the set of possible websites to classify traffic +against. Open World is when the adversary attempts to recognize a specific +website or set of websites out of all possible other traffic. + +The nature of the protocol usage by the application can make this attack +easier or harder, which has resulted in application layer defenses, such as +[ALPACA]. Additionally, the original Google QUIC was easier to fingerprint +than HTTP (See [QUICPRINT1]), but IETF HTTP3 reversed this (See [QUICPRINT2]). +Javascript usage makes these attacks easier (see [INTERSPACE], Table 3), where +as concurrent activity (in the case of TLS observation) makes them harder. +Web3 protocols that exchange blocks of data instead of performing AJAX +requests are likely to be much harder to fingerprint, so long as the web3 +application is accessed via its native protocol, and not via a website +front-end. + +The entire research literature for this vector is fraught with analysis +problems, unfortunately. Because smaller web crawl sizes make the attacks more +effective, and because attack papers are easier to produce than defenses +generally, dismal results are commonplace. [WFNETSIM] and [WFLIVE] examine +some of these effects. It is common for additional hidden gifts to adversaries +to creep in, leading to contradictory results, even in otherwise comprehensive +papers at top-tier venues. The entire vein of literature must be read with a +skeptical eye, a fine-tooth comb, and a large dumpster nearby. + +As one recent example, in an otherwise comprehensive evaluation of modern +defenses, [DEFCRITIC] found a contrary result with respect to the Javascript +finding in the [INTERSPACE] paper, by training and testing their classifiers +with knowledge of the Javascript state of the browser (thus giving them a free +oracle). In truth, neither [DEFCRITIC] nor [INTERSPACE] properly examined the +effects of Javascript -- a rigorous test would train and test on a mix of +Javascript and non-Javascript traffic, and then compare the classification +accuracy of each set separately, after joint classification. Instead, +[DEFCRITIC] just reported that disabling Javascript (via the security level of +Tor Browser) has "no beneficial effect", which they showed by actually letting +the adversary know which traces had Javascript disabled. + +Such hidden gifts to adversaries are commonplace, especially in attack papers. +While it may be useful to do this while comparing defenses against each other, +when these assumptions are hidden, and when defenses are not re-tunable for +more realistic conditions, this leads to focus on burdensome defenses with +large amounts of delay or huge amounts of overhead, at the expense of ignoring +lighter approaches that actually improve the situation in practice. + +This of course means that nothing gets done at all, because Tor is neither +going to add arbitrary cell delay at relays (because of queue memory required +for this and the impacts on congestion control), nor add 400% overhead to +both directions of traffic. + +In terms of defense deployment, it makes the most sense to place these padding +machines at the Guards to start, for many reasons. This is in contrast to +other lighter padding machines for earlier vectors, where it makes more sense +to place them at the middle relay. In this case, the heavier padding machines +necessary for this vector can take advantage of higher multiplexing, which +means less overhead. They can also use the congestion signal at the TLS +connection, to more easily avoid unnecessary padding when the TLS connection +is blocked, thus only using "slack" Guard capacity. Conflux also can be tuned +to provide at least some benefit here: even if in lab conditions it provides +low benefit, in the scenarios studied by [WFNETSIM] and [WFLIVE], this may +actually be considerable, unless the adversary has both guards, which is more +difficult for an internal adversary. Additionally, the distinction between +external and internal adversaries is rarely, if ever, evaluated in the +literature anyway, so there is little guidance on this distinction as a whole, +right now. + + +Solution: Application layer solutions ([ALPACA], disabling Javascript, web3 apps); + Padding machines at guards for application traffic; conflux tuning +Status: Unfixed +Funding: Padding machine and simulator port to arti are funded via Sponsor 112 + + +1.3.4. Protocol or Application Linkability + +At a Glance: + Accuracy: FP=0, FN=0 + Requires: Compromised Exit; Traffic Observation; Hostile Website + Impact: Anonymity Set Reduction + Path Bias: Not Possible + Reason for prioritization: Low impact with faster releases + Signal is: not injected; passively extracted + Signal is observed: at Exit, or at application destination + Signal is: Rare protocol usage or behavior + +Historically, due to Tor's slow upgrade cycles, we have had concerns about +deploying new features that may fragment the anonymity set of early adopters. + +Since we have moved to a more rapid release cycle for both clients and relays +by abandoning the Tor LTS series, these concerns are much less severe. +However, they can still present concerns during the upgrade cycle. For +Conflux, for example, during the alpha series, the fact that few exits +supported conflux caused us to limit the number of pre-built conflux sets to +just one, to avoid concentrating alpha users at just a few exits. It is not +clear that this was actually a serious anonymity concern, but it was certainly +a concern with respect to concentrating the full activity of all these users +at just a few locations, for load balancing reasons alone. + +Similar concerns exist for users of alternate implementations, both of Tor, +and of applications like the browser. We regard this as a potential research +concern, but it is likely not a severe one. For example, assuming Tor Browser +and Brave both address browser fingerprinting, how bad is it for anonymity +that they address it differently? Even if they ensure that all their users +have the same or similar browser fingerprints, it will still be possible for +websites, analytics datasets, and possibly even Exit relays or Exit-side +network observers, to differentiate the use of one browser versus the other. +Does this actually harm their anonymity in a real way, or must other oracles +be involved? Are these oracles easy to obtain? + +Similarly, letting users choose their exit country is in this category. In +some circumstances, this choice has serious anonymity implications: if the +choice is a permanent, global one, and the user chooses an unpopular country +with few exits, all of their activity will be much more linkable. However, if +the country is popular, and/or if the choice is isolated per-tab or per-app, +is this still significant such that it actually enables any real attacks? It +seems like not so much. + +Solutions: Faster upgrade cycle; Avoiding concentrated use of new features +Status: Tor LTS series is no longer supported +Funding: Not explicitly funded + + +1.3.5. Latency Measurement + +At a glance: + Accuracy: FP=high, FN=high + Requires: Onion service, or malicious Exit + Impact: Anonymity Set Reduction/Rough geolocation of services + Path Bias: Possible exacerbating factor + Reason for Prioritization: Low impact; multiple observations required + Signal is created naturally by anything that has a "reply" mechanic + Signal is observed at either end. + Signal is: delays between a message sent and a message received in reply. + +Latency's effects on anonymity set has been studied in the [LATENCY_LEAK] +papers. + +It may be possible to get a rough idea of the geolocation of an onion service +by measuring the latency over many different circuits. This seems more +realistic if the Guard or Guards are known, so that their contribution to +latency statistics can be factored in, over many many connections to an onion +service. For normal client activity, route selection and the fact that the +Exit does not know specific accounts or cookies in use likely provides enough +protection. + +If this turns out to be severe, it seems the best option is to add a delay on +the client side to attempt to mask the overall latency. This kind of approach +is only likely to make sense for onion services. Other path selection +alterations may help, though. + +Solutions: Guards, vanguards, alternative path selection, client-side delay +Status: Guards and vanguards-lite are used in Tor since 0.4.7 +Funding: Not explicitly funded + + +2. Attack Examples + +To demonstrate how info leaks combine, here we provide some historical +real-world attacks that have used these info leaks to deanonymize Tor +users. + + +2.1. CMU Tagging Attack + +Perhaps the most famous historical attack was when a group at CMU assisted the +FBI in performing dragnet deanonymization of Tor users, through their +[RELAY_EARLY] attack on the live network. This attack could only work on users +who happened to use their Guards, but those users could be fully deanonymized. + +The attack itself operated on connections to monitored HSDIRs: it encoded the +address of the onion service in the cell command header, via the RELAY_EARLY +bitflipping technique from Section 1.1.2. Their Guards then recorded this +address, along with the IP address of the user, providing a log of onion +services that each IP address visited. + +It is not clear if the CMU group even properly utilized the full path bias +attack power here to deanonymize as many Tor users as possible, or if their +logs were simply of interest to the FBI because of what they happened to +capture. It seems like the latter is the case. + +A similar, motivated adversary could use any of the covert channels in Section +1.1, in combination with Path Bias to close non-deanonymized circuits, to +fully deanonymize all exit traffic carried by their Guard relays. There are +path bias detectors in Tor to detect large amounts of circuit failure, but +when the network (or the Guard) is also under heavy circuit load, they can +become unreliable, and have their own false positives. + +While this attack vector requires the Guard relay, it is of interest to any +adversary that would like to perform dragnet deanonymization of a wide range +of Tor users, or to compel a Guard to deanonymize certain Tor users. It is +also of interest to adversaries with censorship capability, who would like +to monitor all Tor usage of users, rather than block them. Such an adversary +would use their censorship capability to direct Tor users to only their own +malicious Guards or Bridges. + + +2.2. Guard Discovery Attacks with Netflow Deanonymization + +Prior to the introduction of Vanguards-lite in Tor 0.4.7, it was possible to +combine "1.2.2. Adversary-Induced Circuit Creation", with a circuit-based +covert channel (1.1.3, 1.2.1, or 1.3.2), to obtain a middle relay confirmed +to be next to the user's Guard. + +Once the Guard is obtained, netflow connection times can be used to find the +user of interest. + +There was at least one instance of this being used against a user of Ricochet, +who was fully deanonymized. The user was using neither vanguards-lite, nor the +vanguards addon, so this attack was trivial. It is unclear which covert +channel type was used for Guard Discovery. The netflow attack proceeded +quickly, because the attacker was able to determine when the user was on and +offline via their onion service descriptor being available, and the number +of users at the discovered Guard was relatively small. + + +2.3. Netflow Anonymity Set Reduction + +Netflow records have been used, to varying degrees of success, to attempt to +identify users who have posted violent threats in an area. + +In most cases, this has simply ended up hassling unrelated Tor users, without +finding the posting user. However, in at least one case, the user was found. + +Netflow records were also reportedly used to build suspicion of a datacenter +in Germany which was emitting large amounts of Tor traffic, to eventually +identify it as a Tor hosting service providing service to drug markets, after +further investigation. It is not clear if a flooding attack was also used in +this case. + + +2.4. Application Layer Confirmation + +The first (and only) known case of fine-grained traffic analysis of Tor +involved an application layer confirmation attack, using the vector from +1.3.2. + +In this case, a particular person was suspected as being involved in a group +under investigation, due to the presence of an informant in that group. The +FBI then monitored the suspect's WiFi, and sent a series of XMPP ping messages +to the account in question. Despite the use of Tor, enough pings were sent +such that the timings on the monitored WiFi showed overlap with the XMPP +timings of sent pings and responses. This was prior to Tor's introduction of +netflow padding (which generates similar back-and-forth traffic every 4-9 +seconds between the client and the Guard). + +It should be noted that such attacks are still prone to error, especially for +heavy Tor users whose other traffic would always cause such overlap, as +opposed to those who use Tor for only one purpose, and very lightly or +infrequently. + + +3. Glossary + +Covert Channel: + A kind of information leak that allows an adversary to send information + to another point in the network. + +Collusion Signal: + A Covert Channel that only reliably conveys 1 bit: if an adversary is + present. Such covert channels are weaker than those that enable full + identifier transmission, and also typically require correlation. + +Confirmation Signal: + Similar to a collusion signal, a confirmation signal is sent over a + weak or noisy channel, and can only confirm that an already suspected + entity is the target of the signal. + +False Negative: + A false negative is when the adversary fails to spot the presence of + an info leak vector, in instances where it is actually present. + +False Positive: + A false positive is when the adversary attempts to use an info leak vector, + but some similar traffic pattern or behavior elsewhere matches the traffic + pattern of their info leak vector. + +Guard Discovery: + The ability of an adversary to determine the Guard in use by a service or + client. + +Identifier Transmission: + The ability of a covert channel to reliably encode a unique identifier, + such as an IP address, without error. + +Oracle: + An additional mechanism used to confirm an observed info leak vector + that has a high rate of False Positives. Can take the form of DNS + cache, server logs, analytics data, and other factors. (See [ORACLES]). + +Path Bias (aka Route Manipulation, or Route Capture): + The ability of an adversary to direct circuits towards their other + compromised relays, by destroying circuits and/or TLS connections + whose paths are not sufficiently compromised. + + +Acknowledgments: + +This document has benefited from review and suggestions by David Goulet, Nick +Hopper, Rob Jansen, Nick Mathewson, Tobias Pulls, and Florentin Rochet. + + +References: + +[ALPACA] + https://petsymposium.org/2017/papers/issue2/paper54-2017-2-source.pdf + +[BACKLIT] + https://www.freehaven.net/anonbib/cache/acsac11-backlit.pdf + +[DEEPCOFFEA] + https://www-users.cse.umn.edu/~hoppernj/deepcoffea.pdf + +[DEFCRITIC] + https://www-users.cse.umn.edu/~hoppernj/sok_wf_def_sp23.pdf + +[DNSORACLE] + https://www.usenix.org/system/files/usenixsecurity23-dahlberg.pdf + https://gitlab.torproject.org/rgdd/ttapd/-/tree/main/artifact/safety-board + https://gitlab.torproject.org/tpo/core/tor/-/issues/40674 + https://gitlab.torproject.org/tpo/core/tor/-/issues/40539 + https://gitlab.torproject.org/tpo/core/tor/-/issues/32678 + +[DOSSECURITY] + https://www.princeton.edu/~pmittal/publications/dos-ccs07.pdf + +[DROPMARK] + https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf + +[FLASHFLOW] + https://gitweb.torproject.org/torspec.git/tree/proposals/316-flashflow.md + +[FRONT] + https://www.usenix.org/system/files/sec20summer_gong_prepub.pdf + +[GUARDSETS] + https://www.freehaven.net/anonbib/cache/guardsets-pets2015.pdf + https://www.freehaven.net/anonbib/cache/guardsets-pets2018.pdf + +[INTERSPACE] + https://arxiv.org/pdf/2011.13471.pdf (Table 3) + +[LATENCY_LEAK] + https://www.freehaven.net/anonbib/cache/ccs07-latency-leak.pdf + https://www.robgjansen.com/publications/howlow-pets2013.pdf + +[LYING_SCANNER] + https://gitlab.torproject.org/tpo/network-health/team/-/issues/313 + +[METRICSLEAK] + https://gitlab.torproject.org/tpo/core/tor/-/issues/23512 + +[NETFLOW_TICKET] + https://gitlab.torproject.org/tpo/network-health/team/-/issues/42 + +[ONECELL] + https://www.blackhat.com/presentations/bh-dc-09/Fu/BlackHat-DC-09-Fu-Break-Tors-Anonymity.pdf + +[ONIONPRINT] + https://www.freehaven.net/anonbib/cache/circuit-fingerprinting2015.pdf + +[ONIONFOUND] + https://www.researchgate.net/publication/356421302_From_Onion_Not_Found_to_Guard_Discovery/fulltext/619be24907be5f31b7ac194a/From-Onion-Not-Found-to-Guard-Discovery.pdf?origin=publication_detail + +[ORACLES] + https://petsymposium.org/popets/2020/popets-2020-0013.pdf + +[PADDING_SPEC] + https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/padding-spec.txt#L68 + +[PCP] + https://arxiv.org/abs/2103.03831 + +[QUICPRINT1] + https://arxiv.org/abs/2101.11871 (see also: https://news.ycombinator.com/item?id=25969886) + +[QUICPRINT2] + https://netsec.ethz.ch/publications/papers/smith2021website.pdf + +[RACCOON23] + https://archives.seul.org/or/dev/Mar-2012/msg00019.html + +[RELAY_EARLY] + https://blog.torproject.org/tor-security-advisory-relay-early-traffic-confirmation-attack/ + +[ROBFINGERPRINT] + https://www.usenix.org/conference/usenixsecurity23/presentation/shen-meng + +[SBWS] + https://tpo.pages.torproject.net/network-health/sbws/how_works.html + +[WFLIVE] + https://www.usenix.org/system/files/sec22-cherubin.pdf + +[WFNETSIM] + https://petsymposium.org/2023/files/papers/issue4/popets-2023-0125.pdf diff --git a/proposals/345-specs-in-mdbook.md b/proposals/345-specs-in-mdbook.md new file mode 100644 index 0000000..697134d --- /dev/null +++ b/proposals/345-specs-in-mdbook.md @@ -0,0 +1,254 @@ +``` +Filename: 345-specs-in-mdbook.md +Title: Migrating the tor specifications to mdbook +Author: Nick Mathewson +Created: 2023-10-03 +Status: Open +``` + +# Introduction + +I'm going to propose that we migrate our specifications to a +set of markdown files, specifically using the [`mdbook`] +tool. + +This proposal does _not_ propose a bulk rewrite of our specs; +it is meant to be a low-cost step forward that will produce +better output, and make it easier to continue working on our +specs going forward. + +That said, I think that this change will enable rewrites +in the future. I'll explain more below. + +# What is mdbook? + +Mdbook is a tool developed by members of the Rust community to +create books with [Markdown]. Each chapter is a single +markdown file; the files are organized into a book using a +[`SUMMARY.md`] file. + +Have a look at the [`mdbook` documentation][`mdbook`]; this is +what the output looks like. + +Have a look at this [source tree]: that's the input that +produces the output above. + +Markdown is extensible: it can use numerous [plugins] to +enhance the semantics of the the markdown input, add diagrams, +output in more formats, and so on. + +# What would using mdbook get us _immediately_? + +There are a bunch of changes that we could get immediately via +even the simplest migration to mdbook. These immediate +benefits aren't colossal, but they are things we've wanted for +quite a while. + +* We'll have a document that's easier to navigate (via the sidebars). + +* We'll finally have good HTML output. + +* We'll have all our specifications organized into a single + "document", able to link to one another and cross reference + one another. + +* We'll have perma-links to sections. + +* We'll have a built-in text search function. (Go to the [`mdbook`] + documentation and hit "`s`" to try it out.) + +## How will mdbook help us _later on_ as we reorganize? + +Many of the benefits of mdbook will come later down the line as we +improve our documentation. + +* Reorganizing will become much easier. + + * Our links will no longer be based on section number, so we + won't have to worry about renumbering when we add new sections. + * We'll be able to create redirects from old section filenames + to new ones if we need to rename a file completely. + * It will be far easier to break up our files into smaller files + when we find that we need to reorganize material. + +* We will be able make our documents even _easier_ to navigate. + + * As we improve our documentation, we'll be able to use links + to cross-reference our sections. + +* We'll be able to include real diagrams and tables. + + * We're already using the [`mermaid`] tool in Arti in + generate [protocol diagrams] and [architecture diagrams]; + we can use this in our specs too, instead of hand-drawn + ASCII art. + +* We'll be able to integrate proposals more easily. + + * New proposals can become new chapters in our specification + simply by copying them into a new 'md' file or files; we won't + have to decide between integrating them into existing files + or creating a new spec. + + * Implemented but unmerged proposals can become additional chapters + in an appendix to the spec. We can refer to them with permalinks + that will still work when they move to another place in the specs. + + +# How should we do this? + + +## Strategy + +My priorities here are: + * no loss of information, + * decent-looking output, + * a quick automated conversion process that won't lose a bunch of time. + * a process that we can run experimentally until we are satisfied + with the results + +With that in mind, I'm writing a simple set of [`torspec-converter`] +scripts to convert our old torspec.git repository into its new format. +We can tweak the scripts until we like the that they produce. + +After running a recent `torspec-converter` on a fairly recent +torspec.git, here is how the branch looks: + +https://gitlab.torproject.org/nickm/torspec/-/tree/spec_conversion?ref_type=heads + +And here's the example output when running mdbook on that branch: + +https://people.torproject.org/~nickm/volatile/mdbook-specs/index.html + +> Note: these is not a permanent URL; we won't keep the example output +> forever. When we actually merge the changes, they will move into +> whatever final location we provide. + +The conversion script isn't perfect. It only recognizes three kinds of +content: headings, text, and "other". Content marked "other" is +marked with \`\`\` to reneder it verbatim. + +The choice of which sections to split up and which to keep as a single +page is up to us; I made some initial decisions in the file above, but +we can change it around as we please. See the [configuration section] +at the end of the `grinder.py` script for details on how it's set up. + +## Additional work that will be needed + +Assuming that we make this change, we'll want to build an automated CI +process to build it as a website, and update the website whenever +there is a commit to the specifications. + +(This automated CI process might be as simple as `git clone && mdbook +build && rsync -avz book/ $TARGET`.) + +We'll want to go through our other documentation and update links, +especially the permalinks in spec.torproject.org. + +It might be a good idea to use spec.torproject.org as the new location +of this book, assuming weasel (who maintains spec.tpo) also thinks +it's reasonable. +If we do that, we need to +decide on what we want the landing page to look like, and we need +_very much_ to get our permalink story correct. Right now I'm +generating a .htaccess file as part of the conversion. + + +## Stuff we shouldn't do. + +I think we should continue to use the existing torspec.git repository +for the new material, and just move the old text specs into a new +archival location in torspec. (We *could* make a new repository +entirely, but I don't think that's the best idea. In either case, we +shouldn't change the text specifications after the initial +conversion.) + + +We'll want to figure out our practices for keeping links working as we +reorganize these documents. Mdbook has decent redirect support, but +it's up to us to actually create the redicrets as necessary. + + + +# The transition, in detail + +* Before the transition: + - Work on the script until it produces output we like. + - Finalize this proposal and determine where we are hosting everything. + - Develop the CI process as needed to keep the site up to date. + - Get approval and comment from necessary stakeholders. + - Write documentation as needed to support the new way of doing things. + - Decide on the new layout we want for torspec.git. + +* Staging the transition: + - Make a branch to try out the transition; explicitly allow force-pushing that branch. (Possibly nickm/torspec.git in a branch called mdbook-demo, or torspec.git in a branch called mdbook-demo assuming it is not protected.) + - Make a temporary URL to target with the transition (possibly spec-demo.tpo) + - Once we want to do the transition, shift the scripts to tpo/torspec.git:main and spec.tpo, possibly? + +* The transition: + - Move existing specs to a new subdirectory in torspec.git. + - Run the script to produce an mdbook instance in torspec.git with the right layout. + - Install the CI process to keep the site up to date. + +* Post-transition + - Update links elsewhere. + - Continue to improve the specs. + +# Integrating proposals + +We could make all of our proposals into a separate book, like rust +does at https://rust-lang.github.io/rfcs/ . We could also leave them +as they are for now. + +(I don't currently think we should make all proposals part of the spec +automatically.) + + +# Timing + +I think the right time to do this, if we decide to move ahead, is +before November. That way we have this issue as something people can +work on during the docs hackathon. + +# Alternatives + +I've tried experimenting with Docusaurus here, which is even more +full-featured and generates pretty react sites +[like this](https://docusaurus.io/). +(We're likely to use it for managing the Arti documentation and +website.) + +For the purposes we have here, it seems slightly overkill, but I do +think a migration is feasible down the road if we decide we _do_ want +to move to docusaurus. The important thing is the ability to keep our +URLs working, and I'm confident we could do that + +The main differences for our purposes here seem to be: + + * The markdown implementation in Docusaurus is extremely picky about + stuff that looks like HTML but isn't; it rejects it, rather than + passing it on as text. Thus, using it would require a more + painstaking conversion process before we could include text like + `"<state:on>"` or `"A <-> B"` as our specs do in a few places. + + * Instead of organizing our documents in a `SUMMARY.md` with an MD + outline format, we'd have to organize them in a `sidebar.js` with a + javascript syntax. + + * Docusaurus seems to be far more flexible and have a lot more + features, but also seems trickier to configure. + + + +<-- References --> + +[`mdbook`]: https://rust-lang.github.io/mdBook/ +[source tree]: https://github.com/rust-lang/mdBook/tree/master/guide/src/ +[Markdown]: https://en.wikipedia.org/wiki/Markdown +[`SUMMARY.md`]: https://rust-lang.github.io/mdBook/format/summary.html +[plugins]: https://github.com/rust-lang/mdBook/wiki/Third-party-plugins +[`mermaid`]: https://mermaid.js.org/ +[architecture diagrams]: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/doc/dev/Architecture.md +[protocol diagrams]: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/doc/dev/hs-overview.md +[`torspec-converter`]: https://gitlab.torproject.org/nickm/torspec-converter +[configuration section]: https://gitlab.torproject.org/nickm/torspec-converter/-/blob/main/grinder.py?ref_type=heads#L310
\ No newline at end of file diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md index 16616be..50884b5 100644 --- a/proposals/BY_INDEX.md +++ b/proposals/BY_INDEX.md @@ -15,8 +15,8 @@ Below are a list of proposals sorted by their proposal number. See * [`000-index.txt`](/proposals/000-index.txt): Index of Tor Proposals [META] * [`001-process.txt`](/proposals/001-process.txt): The Tor Proposal Process [META] -* [`098-todo.txt`](/proposals/098-todo.txt): Proposals that should be written [META] -* [`099-misc.txt`](/proposals/099-misc.txt): Miscellaneous proposals [META] +* [`098-todo.txt`](/proposals/098-todo.txt): Proposals that should be written [OBSOLETE] +* [`099-misc.txt`](/proposals/099-misc.txt): Miscellaneous proposals [OBSOLETE] * [`100-tor-spec-udp.txt`](/proposals/100-tor-spec-udp.txt): Tor Unreliable Datagram Extension Proposal [DEAD] * [`101-dir-voting.txt`](/proposals/101-dir-voting.txt): Voting on the Tor Directory System [CLOSED] * [`102-drop-opt.txt`](/proposals/102-drop-opt.txt): Dropping "opt" from the directory format [CLOSED] @@ -182,7 +182,7 @@ Below are a list of proposals sorted by their proposal number. See * [`262-rekey-circuits.txt`](/proposals/262-rekey-circuits.txt): Re-keying live circuits with new cryptographic material [RESERVE] * [`263-ntru-for-pq-handshake.txt`](/proposals/263-ntru-for-pq-handshake.txt): Request to change key exchange protocol for handshake v1.2 [OBSOLETE] * [`264-subprotocol-versions.txt`](/proposals/264-subprotocol-versions.txt): Putting version numbers on the Tor subprotocols [CLOSED] -* [`265-load-balancing-with-overhead.txt`](/proposals/265-load-balancing-with-overhead.txt): Load Balancing with Overhead Parameters [ACCEPTED] +* [`265-load-balancing-with-overhead.txt`](/proposals/265-load-balancing-with-overhead.txt): Load Balancing with Overhead Parameters [OPEN] * [`266-removing-current-obsolete-clients.txt`](/proposals/266-removing-current-obsolete-clients.txt): Removing current obsolete clients from the Tor network [SUPERSEDED] * [`267-tor-consensus-transparency.txt`](/proposals/267-tor-consensus-transparency.txt): Tor Consensus Transparency [OPEN] * [`268-guard-selection.txt`](/proposals/268-guard-selection.txt): New Guard Selection Behaviour [OBSOLETE] @@ -208,7 +208,7 @@ Below are a list of proposals sorted by their proposal number. See * [`288-privcount-with-shamir.txt`](/proposals/288-privcount-with-shamir.txt): Privacy-Preserving Statistics with Privcount in Tor (Shamir version) [RESERVE] * [`289-authenticated-sendmes.txt`](/proposals/289-authenticated-sendmes.txt): Authenticating sendme cells to mitigate bandwidth attacks [CLOSED] * [`290-deprecate-consensus-methods.txt`](/proposals/290-deprecate-consensus-methods.txt): Continuously update consensus methods [META] -* [`291-two-guard-nodes.txt`](/proposals/291-two-guard-nodes.txt): The move to two guard nodes [NEEDS-REVISION] +* [`291-two-guard-nodes.txt`](/proposals/291-two-guard-nodes.txt): The move to two guard nodes [FINISHED] * [`292-mesh-vanguards.txt`](/proposals/292-mesh-vanguards.txt): Mesh-based vanguards [ACCEPTED] * [`293-know-when-to-publish.txt`](/proposals/293-know-when-to-publish.txt): Other ways for relays to know when to publish [CLOSED] * [`294-tls-1.3.txt`](/proposals/294-tls-1.3.txt): TLS 1.3 Migration [DRAFT] @@ -225,7 +225,7 @@ Below are a list of proposals sorted by their proposal number. See * [`305-establish-intro-dos-defense-extention.txt`](/proposals/305-establish-intro-dos-defense-extention.txt): ESTABLISH_INTRO Cell DoS Defense Extension [CLOSED] * [`306-ipv6-happy-eyeballs.txt`](/proposals/306-ipv6-happy-eyeballs.txt): A Tor Implementation of IPv6 Happy Eyeballs [OPEN] * [`307-onionbalance-v3.txt`](/proposals/307-onionbalance-v3.txt): Onion Balance Support for Onion Service v3 [RESERVE] -* [`308-counter-galois-onion.txt`](/proposals/308-counter-galois-onion.txt): Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography [OPEN] +* [`308-counter-galois-onion.txt`](/proposals/308-counter-galois-onion.txt): Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography [SUPERSEDED] * [`309-optimistic-socks-in-tor.txt`](/proposals/309-optimistic-socks-in-tor.txt): Optimistic SOCKS Data [OPEN] * [`310-bandaid-on-guard-selection.txt`](/proposals/310-bandaid-on-guard-selection.txt): Towards load-balancing in Prop 271 [CLOSED] * [`311-relay-ipv6-reachability.txt`](/proposals/311-relay-ipv6-reachability.txt): Tor Relay IPv6 Reachability [ACCEPTED] @@ -241,24 +241,26 @@ Below are a list of proposals sorted by their proposal number. See * [`321-happy-families.md`](/proposals/321-happy-families.md): Better performance and usability for the MyFamily option (v2) [ACCEPTED] * [`322-dirport-linkspec.md`](/proposals/322-dirport-linkspec.md): Extending link specifiers to include the directory port [OPEN] * [`323-walking-onions-full.md`](/proposals/323-walking-onions-full.md): Specification for Walking Onions [OPEN] -* [`324-rtt-congestion-control.txt`](/proposals/324-rtt-congestion-control.txt): RTT-based Congestion Control for Tor [OPEN] +* [`324-rtt-congestion-control.txt`](/proposals/324-rtt-congestion-control.txt): RTT-based Congestion Control for Tor [FINISHED] * [`325-packed-relay-cells.md`](/proposals/325-packed-relay-cells.md): Packed relay cells: saving space on small commands [OBSOLETE] * [`326-tor-relay-well-known-uri-rfc8615.md`](/proposals/326-tor-relay-well-known-uri-rfc8615.md): The "tor-relay" Well-Known Resource Identifier [OPEN] -* [`327-pow-over-intro.txt`](/proposals/327-pow-over-intro.txt): A First Take at PoW Over Introduction Circuits [DRAFT] +* [`327-pow-over-intro.txt`](/proposals/327-pow-over-intro.txt): A First Take at PoW Over Introduction Circuits [FINISHED] * [`328-relay-overload-report.md`](/proposals/328-relay-overload-report.md): Make Relays Report When They Are Overloaded [CLOSED] -* [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting [NEEDS-REVISION] +* [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting [FINISHED] * [`330-authority-contact.md`](/proposals/330-authority-contact.md): Modernizing authority contact entries [OPEN] * [`331-res-tokens-for-anti-dos.md`](/proposals/331-res-tokens-for-anti-dos.md): Res tokens: Anonymous Credentials for Onion Service DoS Resilience [DRAFT] -* [`332-ntor-v3-with-extra-data.md`](/proposals/332-ntor-v3-with-extra-data.md): Ntor protocol with extra data, version 3 [FINISHED] +* [`332-ntor-v3-with-extra-data.md`](/proposals/332-ntor-v3-with-extra-data.md): Ntor protocol with extra data, version 3 [CLOSED] * [`333-vanguards-lite.md`](/proposals/333-vanguards-lite.md): Vanguards lite [FINISHED] * [`334-middle-only-flag.txt`](/proposals/334-middle-only-flag.txt): A Directory Authority Flag To Mark Relays As Middle-only [SUPERSEDED] * [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An authority-only design for MiddleOnly [CLOSED] -* [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries [ACCEPTED] -* [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" [ACCEPTED] +* [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries [CLOSED] +* [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" [CLOSED] * [`338-netinfo-y2038.md`](/proposals/338-netinfo-y2038.md): Use an 8-byte timestamp in NETINFO cells [ACCEPTED] * [`339-udp-over-tor.md`](/proposals/339-udp-over-tor.md): UDP traffic over Tor [ACCEPTED] * [`340-packed-and-fragmented.md`](/proposals/340-packed-and-fragmented.md): Packed and fragmented relay messages [OPEN] * [`341-better-oos.md`](/proposals/341-better-oos.md): A better algorithm for out-of-sockets eviction [OPEN] * [`342-decouple-hs-interval.md`](/proposals/342-decouple-hs-interval.md): Decoupling hs_interval and SRV lifetime [DRAFT] * [`343-rend-caa.txt`](/proposals/343-rend-caa.txt): CAA Extensions for the Tor Rendezvous Specification [OPEN] +* [`344-protocol-info-leaks.txt`](/proposals/344-protocol-info-leaks.txt): Prioritizing Protocol Information Leaks in Tor [OPEN] +* [`345-specs-in-mdbook.md`](/proposals/345-specs-in-mdbook.md): Migrating the tor specifications to mdbook [OPEN] diff --git a/proposals/README.md b/proposals/README.md index 3c6ab14..3c7f8fc 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -22,22 +22,23 @@ for discussion. * [`239-consensus-hash-chaining.txt`](/proposals/239-consensus-hash-chaining.txt): Consensus Hash Chaining * [`240-auth-cert-revocation.txt`](/proposals/240-auth-cert-revocation.txt): Early signing key revocation for directory authorities +* [`265-load-balancing-with-overhead.txt`](/proposals/265-load-balancing-with-overhead.txt): Load Balancing with Overhead Parameters * [`267-tor-consensus-transparency.txt`](/proposals/267-tor-consensus-transparency.txt): Tor Consensus Transparency * [`277-detect-id-sharing.txt`](/proposals/277-detect-id-sharing.txt): Detect multiple relay instances running with same ID * [`287-reduce-lifetime.txt`](/proposals/287-reduce-lifetime.txt): Reduce circuit lifetime without overloading the network * [`295-relay-crypto-with-adl.txt`](/proposals/295-relay-crypto-with-adl.txt): Using ADL for relay cryptography (solving the crypto-tagging attack) * [`303-protover-removal-policy.txt`](/proposals/303-protover-removal-policy.txt): When and how to remove support for protocol versions * [`306-ipv6-happy-eyeballs.txt`](/proposals/306-ipv6-happy-eyeballs.txt): A Tor Implementation of IPv6 Happy Eyeballs -* [`308-counter-galois-onion.txt`](/proposals/308-counter-galois-onion.txt): Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography * [`309-optimistic-socks-in-tor.txt`](/proposals/309-optimistic-socks-in-tor.txt): Optimistic SOCKS Data * [`322-dirport-linkspec.md`](/proposals/322-dirport-linkspec.md): Extending link specifiers to include the directory port * [`323-walking-onions-full.md`](/proposals/323-walking-onions-full.md): Specification for Walking Onions -* [`324-rtt-congestion-control.txt`](/proposals/324-rtt-congestion-control.txt): RTT-based Congestion Control for Tor * [`326-tor-relay-well-known-uri-rfc8615.md`](/proposals/326-tor-relay-well-known-uri-rfc8615.md): The "tor-relay" Well-Known Resource Identifier * [`330-authority-contact.md`](/proposals/330-authority-contact.md): Modernizing authority contact entries * [`340-packed-and-fragmented.md`](/proposals/340-packed-and-fragmented.md): Packed and fragmented relay messages * [`341-better-oos.md`](/proposals/341-better-oos.md): A better algorithm for out-of-sockets eviction * [`343-rend-caa.txt`](/proposals/343-rend-caa.txt): CAA Extensions for the Tor Rendezvous Specification +* [`344-protocol-info-leaks.txt`](/proposals/344-protocol-info-leaks.txt): Prioritizing Protocol Information Leaks in Tor +* [`345-specs-in-mdbook.md`](/proposals/345-specs-in-mdbook.md): Migrating the tor specifications to mdbook ## ACCEPTED proposals: slated for implementation @@ -46,7 +47,6 @@ These are the proposals that we agree we'd like to implement. They might or might not have a specific timeframe planned for their implementation. -* [`265-load-balancing-with-overhead.txt`](/proposals/265-load-balancing-with-overhead.txt): Load Balancing with Overhead Parameters * [`282-remove-named-from-consensus.txt`](/proposals/282-remove-named-from-consensus.txt): Remove "Named" and "Unnamed" handling from consensus voting * [`285-utf-8.txt`](/proposals/285-utf-8.txt): Directory documents should be standardized as UTF-8 * [`292-mesh-vanguards.txt`](/proposals/292-mesh-vanguards.txt): Mesh-based vanguards @@ -54,8 +54,6 @@ implementation. * [`312-relay-auto-ipv6-addr.txt`](/proposals/312-relay-auto-ipv6-addr.txt): Tor Relay Automatic IPv6 Address Discovery * [`313-relay-ipv6-stats.txt`](/proposals/313-relay-ipv6-stats.txt): Tor Relay IPv6 Statistics * [`321-happy-families.md`](/proposals/321-happy-families.md): Better performance and usability for the MyFamily option (v2) -* [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries -* [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" * [`338-netinfo-y2038.md`](/proposals/338-netinfo-y2038.md): Use an 8-byte timestamp in NETINFO cells * [`339-udp-over-tor.md`](/proposals/339-udp-over-tor.md): UDP traffic over Tor @@ -66,7 +64,10 @@ These proposals are implemented in some version of Tor; the proposals themselves still need to be merged into the specifications proper. * [`260-rend-single-onion.txt`](/proposals/260-rend-single-onion.txt): Rendezvous Single Onion Services -* [`332-ntor-v3-with-extra-data.md`](/proposals/332-ntor-v3-with-extra-data.md): Ntor protocol with extra data, version 3 +* [`291-two-guard-nodes.txt`](/proposals/291-two-guard-nodes.txt): The move to two guard nodes +* [`324-rtt-congestion-control.txt`](/proposals/324-rtt-congestion-control.txt): RTT-based Congestion Control for Tor +* [`327-pow-over-intro.txt`](/proposals/327-pow-over-intro.txt): A First Take at PoW Over Introduction Circuits +* [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting * [`333-vanguards-lite.md`](/proposals/333-vanguards-lite.md): Vanguards lite @@ -77,8 +78,6 @@ process. * [`000-index.txt`](/proposals/000-index.txt): Index of Tor Proposals * [`001-process.txt`](/proposals/001-process.txt): The Tor Proposal Process -* [`098-todo.txt`](/proposals/098-todo.txt): Proposals that should be written -* [`099-misc.txt`](/proposals/099-misc.txt): Miscellaneous proposals * [`202-improved-relay-crypto.txt`](/proposals/202-improved-relay-crypto.txt): Two improved relay encryption protocols for Tor cells * [`257-hiding-authorities.txt`](/proposals/257-hiding-authorities.txt): Refactoring authorities and making them more isolated from the net * [`290-deprecate-consensus-methods.txt`](/proposals/290-deprecate-consensus-methods.txt): Continuously update consensus methods @@ -103,7 +102,6 @@ discussion. * [`294-tls-1.3.txt`](/proposals/294-tls-1.3.txt): TLS 1.3 Migration * [`316-flashflow.md`](/proposals/316-flashflow.md): FlashFlow: A Secure Speed Test for Tor (Parent Proposal) -* [`327-pow-over-intro.txt`](/proposals/327-pow-over-intro.txt): A First Take at PoW Over Introduction Circuits * [`331-res-tokens-for-anti-dos.md`](/proposals/331-res-tokens-for-anti-dos.md): Res tokens: Anonymous Credentials for Onion Service DoS Resilience * [`342-decouple-hs-interval.md`](/proposals/342-decouple-hs-interval.md): Decoupling hs_interval and SRV lifetime @@ -119,9 +117,7 @@ certain changes. * [`248-removing-rsa-identities.txt`](/proposals/248-removing-rsa-identities.txt): Remove all RSA identity keys * [`269-hybrid-handshake.txt`](/proposals/269-hybrid-handshake.txt): Transitionally secure hybrid handshakes * [`279-naming-layer-api.txt`](/proposals/279-naming-layer-api.txt): A Name System API for Tor Onion Services -* [`291-two-guard-nodes.txt`](/proposals/291-two-guard-nodes.txt): The move to two guard nodes * [`317-secure-dns-name-resolution.txt`](/proposals/317-secure-dns-name-resolution.txt): Improve security aspects of DNS name resolution -* [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting ## NEEDS-RESEARCH proposals: blocking on research @@ -243,7 +239,10 @@ necessary. * [`315-update-dir-required-fields.txt`](/proposals/315-update-dir-required-fields.txt): Updating the list of fields required in directory documents * [`318-limit-protovers.md`](/proposals/318-limit-protovers.md): Limit protover values to 0-63 * [`328-relay-overload-report.md`](/proposals/328-relay-overload-report.md): Make Relays Report When They Are Overloaded +* [`332-ntor-v3-with-extra-data.md`](/proposals/332-ntor-v3-with-extra-data.md): Ntor protocol with extra data, version 3 * [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An authority-only design for MiddleOnly +* [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries +* [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" ## RESERVE proposals: saving for later @@ -300,6 +299,7 @@ implemented. * [`266-removing-current-obsolete-clients.txt`](/proposals/266-removing-current-obsolete-clients.txt): Removing current obsolete clients from the Tor network * [`280-privcount-in-tor.txt`](/proposals/280-privcount-in-tor.txt): Privacy-Preserving Statistics with Privcount in Tor * [`299-ip-failure-count.txt`](/proposals/299-ip-failure-count.txt): Preferring IPv4 or IPv6 based on IP Version Failure Count +* [`308-counter-galois-onion.txt`](/proposals/308-counter-galois-onion.txt): Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography * [`334-middle-only-flag.txt`](/proposals/334-middle-only-flag.txt): A Directory Authority Flag To Mark Relays As Middle-only @@ -311,6 +311,8 @@ DEAD), the proposal has been considered and not adopted (the proposal is REJECTED), or the proposal addresses an issue or a solution that is no longer relevant (the proposal is OBSOLETE). +* [`098-todo.txt`](/proposals/098-todo.txt): Proposals that should be written [OBSOLETE] +* [`099-misc.txt`](/proposals/099-misc.txt): Miscellaneous proposals [OBSOLETE] * [`100-tor-spec-udp.txt`](/proposals/100-tor-spec-udp.txt): Tor Unreliable Datagram Extension Proposal [DEAD] * [`115-two-hop-paths.txt`](/proposals/115-two-hop-paths.txt): Two Hop Paths [DEAD] * [`116-two-hop-paths-from-guard.txt`](/proposals/116-two-hop-paths-from-guard.txt): Two hop paths from entry guards [DEAD] |