From 3b746784bcef8fb9fdcd51a17bdf6169eb80fe2a Mon Sep 17 00:00:00 2001
From: Mike Perry <mikeperry-git@torproject.org>
Date: Thu, 20 Mar 2025 18:14:49 +0000
Subject: [PATCH 1/2] Prop344: Update and Categorize Vectors; Ground in Threat
 Model

I've re-grounded the entire proposal in Tor's OG Design Doc Threat Model
language, and provide a background of this threat model as part of the
introduction, to help new folks get up to speed and better conceptualize this
proposal.

The proposal has been updated to classify all vectors into the following three
categories:
  1. Internal Covert Channels
  2. Behavior Manipulation
  3. Augmented Observation

It now also proposes that Tor's threat model be expanded to explicitly cover
these categories. These categories (and their vectors) were either explicitly
excluded, or in an ambigous status before.

Additionally, the following vectors have been added:
  - Guard Trapper Attacks
  - Relay DoS/OOM

The following examples have been added to existing vectors
  - Path restriction problems
  - .exit notation
  - Exit Policy abuse by websites+exits
  - circuit dirtyness abuse by exits
  - Dropped cells types unique to onion services
---
 proposals/000-index.txt              |    4 +-
 proposals/344-protocol-info-leaks.md | 1023 +++++++++++++++++---------
 proposals/BY_INDEX.md                |    2 +-
 proposals/BY_STATUS.md               |    2 +-
 proposals/SUMMARY.md                 |    2 +-
 5 files changed, 674 insertions(+), 359 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 22931af4..c7f31c12 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -265,7 +265,7 @@ Proposals by number:
 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]
+344  Information Leak Hazards for Tor Implementations [OPEN]
 345  Migrating the tor specifications to mdbook [CLOSED]
 346  Clarifying and extending the use of protocol versioning [OPEN]
 347  Domain separation for certificate signing keys [OPEN]
@@ -313,7 +313,7 @@ Proposals by status:
    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
+   344  Information Leak Hazards for Tor Implementations
    346  Clarifying and extending the use of protocol versioning
    347  Domain separation for certificate signing keys
    348  UDP Application Support in Tor
diff --git a/proposals/344-protocol-info-leaks.md b/proposals/344-protocol-info-leaks.md
index 2740e2c0..a188c244 100644
--- a/proposals/344-protocol-info-leaks.md
+++ b/proposals/344-protocol-info-leaks.md
@@ -1,87 +1,35 @@
 ```
 Filename: 344-protocol-info-leaks.md
-Title: Prioritizing Protocol Information Leaks in Tor
+Title: Information Leak Hazards for Tor Implementations
 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.
+# Table of Contents
 
-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-info-leak-vectors)
-   - 1.1. [Highly Severe Covert Channel Vectors](#11-highly-severe-covert-channel-vectors)
+0. [Introduction](#0-introduction)
+   - 0.1. [Background: Gaps in Tor's Original Threat Model](#01-background-gaps-in-tors-original-threat-model)
+1. [Closing the Gaps](#1-closing-the-gaps)
+   - 1.1. [Highly Severe Internal Covert Channel Vectors](#11-highly-severe-internal-covert-channel-vectors)
      - 1.1.1. [Cryptographic Tagging](#111-cryptographic-tagging)
      - 1.1.2. [End-to-end cell header manipulation](#112-end-to-end-cell-header-manipulation)
      - 1.1.3. [Dropped cells](#113-dropped-cells)
-   - 1.2. [Info Leaks that enable other attacks](#12-info-leaks-that-enable-other-attacks)
-     - 1.2.1. [Handshakes with unique traffic patterns](#121-handshakes-with-unique-traffic-patterns)
+   - 1.2. [Zero-Click Behavior Manipulation Primitives](#12-zero-click-behavior-manipulation-primitives)
+     - 1.2.1. [Guard Trapping Attacks](#121-guard-trapping-attacks)
      - 1.2.2. [Adversary-Induced Circuit Creation](#122-adversary-induced-circuit-creation)
-     - 1.2.3. [Relay Bandwidth Lying](#123-relay-bandwidth-lying)
-     - 1.2.4. [Metrics Leakage](#124-metrics-leakage)
-     - 1.2.5. [Protocol Oracles](#125-protocol-oracles)
-   - 1.3. [Info Leaks of Research Concern](#13-info-leaks-of-research-concern)
-     - 1.3.1. [Netflow Activity](#131-netflow-activity)
-     - 1.3.2. [Active Traffic Manipulation Covert Channels](#132-active-traffic-manipulation-covert-channels)
-     - 1.3.3. [Passive Application-Layer Traffic Patterns](#133-passive-application-layer-traffic-patterns)
-     - 1.3.4. [Protocol or Application Linkability](#134-protocol-or-application-linkability)
-     - 1.3.5. [Latency Measurement](#135-latency-measurement)
+     - 1.2.3. [Handshakes with unique traffic patterns](#123-handshakes-with-unique-traffic-patterns)
+     - 1.2.4. [Relay DoS/OOM Attacks](#124-relay-dosoom-attacks)
+     - 1.2.5. [Relay Bandwidth Lying](#125-relay-bandwidth-lying)
+   - 1.3. [Augmented Observation Primitives](#13-augmented-observation-primitives)
+     - 1.3.1. [Netflow Observation](#131-netflow-observation)
+     - 1.3.2. [Metrics Leakage](#132-metrics-leakage)
+     - 1.3.3. [Protocol Oracles](#133-protocol-oracles)
+     - 1.3.4. [Active Traffic Manipulation Covert Channels](#134-active-traffic-manipulation-covert-channels)
+     - 1.3.5. [Passive Application-Layer Traffic Patterns](#135-passive-application-layer-traffic-patterns)
+     - 1.3.6. [Protocol or Application Linkability](#136-protocol-or-application-linkability)
+     - 1.3.7. [Latency Measurement](#137-latency-measurement)
 2. [Attack Examples](#2-attack-examples)
    - 2.1. [CMU Tagging Attack](#21-cmu-tagging-attack)
    - 2.2. [Guard Discovery Attacks with Netflow Deanonymization](#22-guard-discovery-attacks-with-netflow-deanonymization)
@@ -89,39 +37,181 @@ occurring with respect to Tor cases. Still, keep your eyes peeled...
    - 2.4. [Application Layer Confirmation](#24-application-layer-confirmation)
 3. [Glossary](#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
+# 0. Introduction
+
+This document clarifies and expands Tor's threat model, in order to rank and
+categorize existing and historical information leaks in the Tor Protocol and
+Tor Behavior. It is also intended to be useful as a developer introduction to
+hazards in Tor protocol feature design, as well as hazards in Tor client
+behavior 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 most of these issues.
+
+Readers who are relatively new to anonymity literature may wish to first
+consult the Glossary in [Section 3](#3-glossary), 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](#2-attack-examples), 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](#2-attack-examples) 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 we are not aware of any direct
+evidence of this occurring with respect to Tor cases. Keep your eyes peeled...
+
+## 0.1. Background: Gaps in Tor's Original Threat Model
+
+Tor's [original threat
+model](https://svn-archive.torproject.org/svn/projects/design-paper/tor-design.html#subsec:threat-model)
+focused on local adversaries who can observe limited portions of the Tor
+network, excluding global adversaries with full network visibility.
+
+In this model, the distributed trust properties of a network run by multiple
+distinct entities worked in Tor's favor. A local adversary observing a
+fraction `(c/n)` of the network's entrance and exit capacity is expected to
+deanonymize only `(c/n)^2` of traffic, thanks to Tor's random entrance and
+exit selection. (This compromise estimate was altered slightly, to account
+for guard nodes; see part 2 of [\[TOR_DESIGN_UPDATES\]][refs]. We retain
+the original estimate for simplicity of explanation.)
+
+Though not required by a local adversary threat model, Tor also considered
+**traffic confirmation attacks**—where an adversary observes both ends of a
+communication to confirm its occurrence—to be out of scope. Tor's threat model
+implicitly assumed that such observations were always 100% accurate and not
+worth defending against in specific. This assumption underpins the `(c/n)^2`
+deanonymization estimate.
+
+Tor's original design paper defined **traffic analysis attacks** as attacks
+where an adversary uses traffic patterns to learn where they need to attack,
+in order to maximize the utility of its `c/n` observation capability. Tor
+considers these attacks to be in scope.
+
+Tor's original threat model scope falls short in three areas, which we propose
+to be now explicitly in-scope, as valid Tor attack categories warranting
+development prioritization, and future funding allocation consideration:
+
+1. **Internal Covert Channels**: Traffic confirmation vectors in the Tor Protocol
+itself provide *highly severe internal covert channels* that relays can use to
+manipulate circuit use (Path Bias), in ways that are invisible to users and
+applications. The resulting path bias capability completely removes Tor's
+distributed trusty property at malicious Guard relays, and malicious ISPs.
+
+2. **Behavior Manipulation**: Traffic analysis attacks can make use of various
+*zero-click behavior manipulation primitives* to elicit specific unique Tor protocol
+activity, and to erode Tor's distributed trust property to observe it. The
+resulting Tor protocol activity provides a traffic confirmation vector
+that they can reliably observe, on demand, without requiring any
+user-initiated application activity.
+
+3. **Augmented Observation**: Traffic confirmation attacks can be built upon
+mechanisms of *augmented observation primitives* that enable an adversary to
+construct low-resolution approximations of global adversaries, through novel
+forms of traffic observation. In these cases, we now have practical,
+real-world attack scenarios where traffic observation does not guarantee
+traffic confirmation with 100% accuracy, in ways that matter to defense
+development and deployment.
+
+Over the past two decades of academic research and real-world attacks on the
+Tor network, all significant attacks have been related to one of these three
+categories of threat model gap.
+
+Unfortunately, the implicit 100% accuracy assumption of observation for
+traffic confirmation has also made it difficult to evaluate the relative
+severity of Tor protocol information leaks, both inside and across these
+categories.
+
+However, as we shall see, the three above areas also correspond to a severity
+ordering: Covert Channels directly inside the Tor Protocol yield more
+comprehensive deanonymization capability than Behavior Manipulation, and
+Behavior Manipulation typically is used to assist Augmented Observation to
+become sufficiently accurate for deanonymization.
+
+To support this ordering, we will examine the kinds of attacks each
+information leak vector in each category enables, in terms of their
+deanonymization capability. This examination will also drive the severity
+ordering of each vector within its category. The most severe vectors are
+listed first, in both cases.
+
+Each vector of information leak also has a common solution, and some vectors
+share the same solution as other vectors.
+
+# 1. Closing the Gaps
+
+In this section, we prioritize and categorize the info leak vectors that exist
+in the three new areas of Tor's threat model, in order of highest priority
+first.
+
+Corresponding to the expanded threat model's new categories, these categories
+are: "Highly Severe Covert Channels", "Zero-Click Behavior Manipulation
+Primitives", and "Augmented Observation Primitives".
+
+The first category allows malicious relays to communicate their presence in a
+circuit prior to any application traffic, which yields dragnet deanonymization
+attacks by itself. The second category are properties of Tor's Protocol and
+client behavior that can be used to assist attacks that can lead to arbitrary
+deanonymization. The final category covers information leaks that enable a
+local adversary to approximate a global adversary, typically assisted by
+earlier vectors, or outside information, to improve confirmation accuracy.
+
+For each vector, we provide a brief "at-a-glance" summary table, 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.
 
+At the end of each section, we provide another table with the mitigation plans
+and status of that vector.
+
+## 1.1. Highly Severe Internal Covert Channel Vectors
+
+A covert channel is a mechanism by which malicious entities in a communication
+channel can recognize and communicate with each other.
+
+Highly Severe Internal Covert Channels are created by traffic confirmation
+vectors inside of Tor's protocol.
+
+In order to be classified as Highly Severe, a covert channel vector must
+satisfy three properties:
+
+  1. It must be usable before a circuit is carrying application traffic.
 
-## 1.1. Highly Severe Covert Channel Vectors
+  2. It must be immediately recognizable as an end-to-end collusion signal on
+a circuit, such that the adversary can confidently close all circuits that do
+not contain this signal.
 
-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.
+  3. It must have a zero or near-zero false positive and false negative rate
+for this collusion signal.
 
-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.
+These three properties enable relays to fail all circuits that are not
+deanonymized (a process called Path Bias). This removes a `c/n` factor of
+Tor's distributed trust properties, increasing these relays' share of
+deanonymized Tor traffic from the expected `(c/n)^2` to `c/n`.
 
-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.
+To highlight how vectors can combine: If the adversary also has the [Guard
+trapping capability from Section 1.2.1](#121-guard-trapping-attacks) to censor
+Tor clients to use only specific Guards, it can ensure that users only connect
+to compromised Guards (or Bridges). These Guards can in turn use this
+section's covert channels to ensure that all of these circuits are directed
+only to compromised Exits. This removes both `c/n` factors, fully
+deanonymizing all users who are subject to this censorship firewall. In these
+specific circumstances, Tor is actually less secure than a 1-hop VPN.
+
+> This style of censorship-based deanonymization attack was first academically
+> published in [\[TRAPPING_TOR\]][refs], and it also includes a covert
+> channel. However, their covert channel (stream correlation) does not satisfy
+> the first requirement of this section, because it relies on streams already
+> sending data. In practice, this means that targeted users would notice their
+> connections were repeatedly being terminated mid-download, and would have
+> great difficulty actually using Tor to download anything. The covert
+> channels in this section, by contrast, enable closing circuits *before*
+> application traffic begins, thus making them invisible to targeted users,
+> other than as a higher circuit failure rate.
 
 ### 1.1.1. Cryptographic Tagging
 
@@ -138,12 +228,13 @@ users with these covert channels.
 | **Signal is injected**: | by guard |
 | **Signal is observed**: | by exit |
 
-First reported at Black Hat in 2009 (see [\[ONECELL\]][refs]), and elaborated further
-with the path bias amplification attack in 2012 by some Raccoons (see
-[\[RACCOON23\]][refs]), this is the most severe vector of covert channel attack in Tor.
+First reported at Black Hat in 2009 (see [\[ONECELL\]][refs]), and elaborated
+further with the path bias amplification attack in 2012 by some Raccoons (see
+[\[RACCOON23\]][refs]), 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
+XORs an identifier, such as the client's 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
@@ -156,15 +247,21 @@ 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.
+(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 use this vector in combination with the [guard
+trapping attacks.](#121-guard-trapping-attacks) vector, in Section 2.
 
 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).
+their Exit capacity.
+
+If the adversary does not have censorship capability, relays can [lie about
+their bandwidth](#125-relay-bandwidth-lying), or [DoS other
+guards](#124-relay-dosoom-attacks) to make themselves more likely to be chosen
+as Guards.
 
 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
@@ -195,7 +292,7 @@ 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 |
+| **Funding**: | CGO explicitly funded via Project 112 |
 
 
 ### 1.1.2. End-to-end cell header manipulation
@@ -210,8 +307,8 @@ adversary also ends up in the HSDIR position, for deanonymization.
 | **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 |
+| **Signal is injected**: | By either guard or exit/HSDIR/IP |
+| **Signal is observed**: | By either guard or exit/HSDIR/IP |
 
 The Tor protocol consists of both cell header commands, and relay header
 commands. Cell commands are not encrypted by circuit-level encryption, so they
@@ -233,36 +330,42 @@ 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
+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 provide a path bias amplification attack to dropped cell
+covert channel attacks. In this case, these 3-5 bits would just be a collusion
+signal to the exit to keep the circuit (or to close it when the signal is
+absent). This will reduce the amount of non-compromised traffic that malicious
+exit must carry (see the following [Section 1.1.3](#113-dropped-cells)). If
+the adversary is an ISP with censorship capability, this combined vector can
+be used to deanonymize all Tor traffic at that ISP, using
+[\[TRAPPER_TOR\]][refs] Guard filtering.
+
+While more cumbersome than cryptographic tagging attacks from [Section
+1.1.1](#111-cryptographic-tagging), 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](#21-cmu-tagging-attack)
+before cryptographic tagging, but perhaps that was just a lucky coincidence of
 opportunity.
 
+The CGO proposal (an updated form of Prop#308) will eliminate the ability of
+Guards to alter cell commands via a MAC, but Exits, HSDir, and Intro Point
+relays will still be able to make use of the vector towards the client, if it
+is not mitigated at the client. Additionally, this MAC will not prevent this
+covert channel from being used all the way from an onion client to an onion
+service, or vice-versa, on a rend circuit, especially one with a malicious RP
+relay.
+
 **Mitigation Plan**:
 
 | **Action** | **Details** |
 |----|----|
 | **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 |
+| **Funding**: | Arti and relay-side fixes are explicitly funded via Project 112 |
 
 
 ### 1.1.3. Dropped cells
@@ -277,33 +380,39 @@ opportunity.
 | **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 injected**: | By exit, HSDIR, or Intro Point, or client |
 | **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
+  - 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
+
+Additionally, clients can send arbitrary relay commands to onion services, which includes the above set, plus:
+  - RELAY_BEGIN to invalid addrs/ports
+  - RELAY_BEGIN to reused stream-ids
+  - Relay commands normally reserved for relays or exits
+  - Unsupported optimistic data
+
+The attack works by injecting inbound RELAY cells at the exit, HSDir, Intro
+Point, or client, and then observing anomalous traffic patterns at the guard
+or at the client->guard connection.
+
+The accuracy of this covert channel is extremely high (zero false positives; zero
+false negatives) when these cells 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)
+  - When the onion service client is adversarial
 
 Because of the stateful and deterministic nature of the Tor protocol,
 especially handshakes, it is easy to accurately recognize these specific cases
@@ -315,58 +424,217 @@ 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).
+manipulation.
+
+Consistent with the criteria for [Section
+1.1](#11-highly-severe-internal-covert-channel-vectors), this ability to use the
+collusion signal to perform path bias before circuit use differentiates
+dropped cells within the Tor Protocol from dead weight traffic during
+application usage (such as javascript requests for 404 URLs, covered in
+[Section 1.3.4](#134-active-traffic-manipulation-covert-channels)).
 
 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\]][refs]. 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
+itself, for two main reasons:
+   1. First, the collusion signal is only one way: the Exit can't use this
+covert channel to close circuits that are carried by a non-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, to carry
+out deanonymization with this vector alone. These kinds of more subtle
+trade-offs with respect to path bias are covered in [\[DOSSECURITY\]][refs].
+   2. 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.
+minimal, 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.
 
 **Mitigation Plan**:
 
 | **Action** | **Details** |
 |----|----|
-| **Solution**: | Forthcoming dropped-cell proposal |
+| **Solution**: | [Prop#349: Relay command state validation](https://spec.torproject.org/proposals/349) |
 | **Status**: | Fixed with vanguards addon; Unfixed otherwise |
-| **Funding**: | Arti and relay-side fixes are explicitly funded via Sponsor 112 |
+| **Funding**: | Arti and relay-side fixes are explicitly funded via Project 112 |
+
+## 1.2. Zero-Click Behavior Manipulation Primitives
+
+These info leaks are less severe than the first group, because they do not
+provide full control of all circuit usage, by themselves.
+
+Instead, they enable the adversary to control or manipulate client behavior,
+and combine it with relative uniqueness of Tor Protocol handshake traffic
+patterns, to build potent attacks, without any user-initiated application
+activity. In some cases, this still results in full deanonymization.
+
+Importantly, these information leaks and their resulting attacks still are
+entirely the fault of the Tor Protocol and Tor implementation behavior, and
+are not inherent to low-latency mix networks in general.
+
+### 1.2.1. Guard Trapping Attacks
+
+**At a glance:**
+
+| **Characteristic** | **Information** |
+|----|-----|
+| **Accuracy**: | FP=0, FN=0 |
+| **Requires**: | Local ISP or Censorship Firewall, at least one Guard |
+| **Impact**: | Guard choice control |
+| **Path Bias**: | Provides control of Guard, which can perform previous attacks |
+| **Reason for Prioritization**: | Full deanonymization of all client traffic, with other vectors |
+| **Signal is**:| Tor trying guards/bridges until one succeeds |
+| **Signal is injected**: | By client behavior |
+| **Signal is observed**: | At ISP/Guard |
+
+As already mentioned, an adversary with a censorship firewall, local network,
+or ISP control can restrict a Tor client to only connect to their malicious
+Guard relays. They can then perform full deanonymization of all Tor client
+traffic on their network, using an internal covert channel from the previous
+section.
+
+This attack vector is possible primarily because Tor clients continually try
+to connect to Guard relays until enough primary guard connections succeed,
+without stopping to alert the user at any point. This behavior is an artifact
+of from before Tor Browser had easy-to-use bridge autoconfiguration; in the
+hope it might help some forms of censored clients connect easier. Now,
+however, it is not necessary. (Tor Browser bridge autoconfiguration is rate
+limited, which minimizes this attack vector there).
+
+This style of censorship-based deanonymization attack was first academically
+published in [\[TRAPPING_TOR\]][refs]. It is worth repeating that their covert
+channel in that paper is stream data correlation. We do not find this to be a
+realistic fallback, because for most applications, the repeated connection
+termination mid-download will be noticeable to the user, and will make their
+application unusable.
+
+If the internal covert channel vectors from Section 1 are fixed, the adversary
+is more likely to use this vector in combination with other behavior
+manipulation vectors in this section, in order to induce a noticeable pattern
+at their Guard. If they are attacking an onion service, or have control of a
+website used by their target, they can use [active traffic
+manipulation](#134-active-traffic-manipulation-covert-channels) to confirm
+activity at their Guard, to deanonymize the user.
+
+In order to mitigate this attack, Tor clients need to be less aggressive with
+probing Guards until they succeed, and alert the user if too many fail,
+instead of silently succeeding. If [\[GUARDSETS\]][refs] is implemented,
+clients could refuse to use anything other than a specific set of guards.  It
+would also make it more challenging for such an adversary to control all
+client guards in a set.
+
+**Mitigation Plan**:
+
+| **Action** | **Details** |
+|----|----|
+| **Solution**: | Limiting Guard Connections; GuardSets |
+| **Status**: | Not Implemented |
+| **Funding**: | Not explicitly funded |
+
+
+### 1.2.2. Adversary-Induced Circuit Creation
+
+**At a glance:**
+
+| **Characteristic** | **Information** |
+|----|-----|
+| **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](#11-highly-severe-internal-covert-channel-vectors), with a unique handshake from
+[Section 1.2.3](#123-handshakes-with-unique-traffic-patterns), or with active
+traffic manipulation ([Section
+1.3.4](#134-active-traffic-manipulation-covert-channels)), 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](#131-netflow-observation)).
+
+This vector also becomes severe when the adversary can additionally *control*
+some aspect of the circuit construction that a client performs. The first case
+of this being problematic was so-called .exit notation, where Tor allowed an
+application to specify their desired exit by appending it to the domain
+name. Applications that handle untrusted data, such as the browser, could be
+induced to build circuits to malicious exits, for deanonymization attacks.
+
+Since then, additional sources of these cases has been through Tor's Path
+Restrictions. By preventing circuits with specific relays in two positions of
+a circuit, Tor can reveal information to the ISP, or directly to the
+adversary, through Tor's application of path restrictions under repeated
+circuit creation attempts with adversary-controlled relay choice (RP, IP,
+HSDir, or using a custom unique Exit Policy on their Exit).
+
+C-Tor has patched several cases of adversarially-induced path restriction
+related information leaks in the past. An illustrative example is [Bug
+14917](https://gitlab.torproject.org/tpo/core/tor/-/issues/14917), where Tor's
+single guard use allowed the adversary to either learn that guard, or collude
+with the local ISP to confirm client activity, through choice of the RP. Tor
+no longer applies restrictions to onion service circuits, but there is a
+minefield of problems that can still reappear in various circumstances with
+these restrictions. See [Proposal
+354](https://spec.torproject.org/proposals/354) for those details, and for a
+proposed set of restrictions that do not leak this information.
 
-## 1.2. Info Leaks that enable other attacks
+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
+  - Malicious javascript that abuses the circuit dirty timeout to continually
+    build circuits, slowly, on browser tabs left open for long periods
+  - Repeated Conflux leg failures
 
-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.
+Tor now uses [Vanguards](https://spec.torproject.org/vanguards-spec/index.html) to
+protect onion service activity. The system comes in two flavors: Lite and
+Full. Vanguards-Lite 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. Full Vanguards uses two layers of vanguards, and expected
+use cases of months.
 
+These attack times are probabilistic expectations, and are rough estimates.
+See the [statistical analysis in the spec](https://spec.torproject.org/vanguards-spec/vanguards-stats.html) 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.4](#134-active-traffic-manipulation-covert-channels)), which will resemble
+an application layer DoS or flood, and can be defended against at the application
+layer.
+
+Prior to the implementation of Vanguards, at least one user is known to have [been deanonymized by Guard Discovery](#22-guard-discovery-attacks-with-netflow-deanonymization), through this vector.
+
+Non-Onion service activity, such as Conflux leg failures, is protected by
+feature-specific rate limits. Exit policy manipulation is scanned for on the
+network. The circuit dirty timeout issue remains unaddressed.
+
+**Mitigation Plan**:
+
+| **Action** | **Details** |
+|----|----|
+| **Solution**: | Vanguards; Prop#354; rate limiting circuit creation attempts; rate limiting the total number of distinct paths used by circuits; simplifying restrictions; eliminating circuit dirty timeout |
+| **Status**: | Vanguards-lite deployed in Tor 0.4.7; Mesh-vanguards is vanguards addon; Arti supports Vanguards Lite and full; Conflux leg failures are limited per-exit; Exitpolicy scanner exists; C-Tor exempts many problematic cases of path restrictions |
+| **Funding**: | Not explicitly funded |
 
-### 1.2.1. Handshakes with unique traffic patterns
+
+### 1.2.3. Handshakes with unique traffic patterns
 
 **At a glance:**
 
@@ -376,7 +644,7 @@ fingerprinting.
 | **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 |
+| **Reason for Prioritization**: | Increases severity of vectors [1.2.2](#122-adversary-induced-circuit-creation) and [1.3.5](#135-passive-application-layer-traffic-patterns) |
 | **Signal is**:| Unique cell patterns |
 | **Signal is injected**: | By client's behavior |
 | **Signal is observed**: | At guard |
@@ -414,14 +682,16 @@ 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\]][refs] guard
-discovery attack, and they provide a measurement of its uniqueness.
+uniquely recognizable. This fingerprint was used in the [\[ONIONFOUND\]][refs]
+guard discovery attack in combination with a circuit creation vector ([Section
+1.2.2](#122-adversary-induced-circuit-creation)). The authors provide a
+measurement of its uniqueness in that paper.
 
 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
+fingerprinting (see [Section 1.3.3](#113-dropped-cells)), making that attack realistic and
 practical. Effectively, it functions as a kind of oracle in this case (see
-Glossary, and [\[ORACLES\]][refs]).
+[Glossary](#3-glossary), and [\[ORACLES\]][refs]).
 
 **Mitigation Plan**:
 
@@ -432,69 +702,45 @@ Glossary, and [\[ORACLES\]][refs]).
 | **Funding**: | Not explicitly funded |
 
 
-### 1.2.2. Adversary-Induced Circuit Creation
+### 1.2.4. Relay DoS/OOM Attacks
 
 **At a glance:**
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **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.
+| **Accuracy**: | FP=0, FN=0 |
+| **Requires**: | Running relays in the network |
+| **Impact**: | Clients migrate to malicious relays |
+| **Path Bias**: | May provide adversary with control of target's Guard or HSDir |
+| **Reason for prioritization**: | Assists/enhances any Guard or HSDir attack vector |
+| **Signal is**:| Currently open connections closing; removal of Guard and HSDir flag of targeted relays |
+| **Signal is injected**: | By crashing targeted relays |
+| **Signal is observed**: | By clients; By malicious relays who retain Guard and HSDir flags |
+
+An adversary that is able to crash or otherwise knock a relay offline is able
+to remove that relay's Guard and HSDir flags. This attack is explored in the
+[\[SNIPER\]][refs] papers.
+
+If the adversary is also running Guard or HSDir relays, they can selectively
+attack other relays, in an attempt to cause clients and services to migrate to
+their malicious ones, from which they can make use of additional attack
+vectors, or engage in censorship.
+
+An adversary can confirm that a Guard is used by an onion service by
+maintaining a connection to it while taking it offline, to watch the
+connection close. Such an adversary may be more interested in the resulting
+Guard discovery surveillance opportunities, rather than removing the Guard
+flag itself.
 
 **Mitigation Plan**:
 
 | **Action** | **Details** |
 |----|----|
-| **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 |
+| **Solution**: | C-Tor has an oom killer to free memory under pressure; Circuits with excessive queues are force-closed at relays |
+| **Status**: | C-Tor OOM killer may have edge cases |
+| **Funding**: | Fixes covered by Project 112 |
 
-
-### 1.2.3. Relay Bandwidth Lying
+### 1.2.5. Relay Bandwidth Lying
 
 **At a glance:**
 
@@ -529,12 +775,12 @@ 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.
+from [Section 1.1](#11-highly-severe-internal-covert-channel-vectors): 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:
@@ -545,9 +791,10 @@ measurement problem. These have not been deployed for three reasons:
 
 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\]][refs].
-(Note that FlashFlow still needs [\[SBWS\]][refs] or another mechanism to handle load
-balancing, though, since FlashFlow only provides measurement).
+distributed and/or dedicated measurement components, such as
+[\[FLASHFLOW\]][refs].  (Note that FlashFlow still needs [\[SBWS\]][refs] or
+another mechanism to handle load balancing, though, since FlashFlow only
+provides measurement).
 
 **Mitigation Plan**:
 
@@ -555,10 +802,119 @@ balancing, though, since FlashFlow only provides measurement).
 |----|----|
 | **Solution**: | Scan for lying relays; implement research measurement solutions |
 | **Status**: | A sketch of the lying relay scanner design is in [\[LYING_SCANNER\]][refs] |
-| **Funding**: | Scanning for lying relays is funded via Sponsor 112 |
+| **Funding**: | Scanning for lying relays is funded via Project 112 |
+
+
+## 1.3. Augmented Observation Primitives
+
+Augmented Observation Primitives provide a local adversary with additional ability
+to observe network traffic, in ways that improve their ability to carry out
+confirmation attacks with one-sided direct observation, and/or with observation in
+limited resolution.
+
+In effect, these vectors all assist a local adversary in constructing an
+*approximation* of a global adversary, with varying degrees of accuracy.
+Vectors are included here because they are either foundational to this
+construction, or because they assist in improving the accuracy of this
+approximation.
+
+Under these augmented observation vectors, confirmation accuracy varies
+greatly depending on traffic pattern uniqueness, traffic quantity, traffic
+duration, multiplexing properties, augmented observation data retention
+resolution, and the number of similar traffic flows being compared.
+
+With this in mind, while these observation vectors do not yield reliable, full
+scale deanonymization by themselves, they can still do so when they are part
+of a combined attack, such as with Guard Discovery from the previous section.
+Traffic modification and injection can also significantly enhance confirmation
+capabilities by creating unique, observable signals, for use in Netflow
+analysis, for example.
+
+Some of these may be more or less severe than currently suspected, especially
+relative to each other, under various defenses, and/or when combined with other
+sources of information. This entire category remains under active research,
+for both attacks and defenses.
+
+### 1.3.1. Netflow Observation
+
+**At a glance:**
+
+| **Characteristic** | **Information** |
+|----|-----|
+| **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**:| Connection tuple times and byte counts |
+| **Signal is injected**: | Created by using the network |
+| **Signal is observed**: | At ISP of everything that is using the network |
+
+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\]][refs]. This Netflow data
+market effectively creates a low-resolution global passive adversary, for
+anyone who buys enough Netflow record datasets, or pays for access to analysis
+of these datasets.
+
+Tor has a padding mechanism to reduce the resolution of this data (see Section
+2 of [\[PADDING_SPEC\]][refs]), 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\]][refs].
+
+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\]][refs]. 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.
+
+When [Netflow data is used by itself](#23-netflow-anonymity-set-reduction) in
+the wild, it tends to result in the hassling of multiple innocent Tor users
+rather than confirming a particular individual. However, is [has been used
+successfully](#22-guard-discovery-attacks-with-netflow-deanonymization) in
+combination with Guard Discovery.
+
+**Mitigation Plan**:
+
+| **Action** | **Details** |
+|----|----|
+| **Solution**: | 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.2.4. Metrics Leakage
+### 1.3.2. Metrics Leakage
 
 **At a glance:**
 
@@ -574,7 +930,15 @@ balancing, though, since FlashFlow only provides measurement).
 | **Signal is observed**: | By reading router descriptors |
 
 In the past, we have had issues with info leaks in our metrics reporting (see
-[\[METRICSLEAK\]][refs]). We addressed them by lowering the resolution of read/write
+[\[METRICSLEAK\]][refs]), where our own relay metrics effectively provided
+a global passive adversary with enough resolution to recognize certain kinds
+of traffic.
+
+Under such conditions of improper operation, this vector is quite severe, and
+can be combined with even limited netflow data to construct a global
+adversary, and deanonymize onion services.
+
+We addressed these issues 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.
@@ -592,7 +956,7 @@ in use by onion services, and thus discover its Guards.
 | **Funding**: | Not funded |
 
 
-### 1.2.5. Protocol Oracles
+### 1.3.3. Protocol Oracles
 
 **At a glance:**
 
@@ -609,14 +973,17 @@ in use by onion services, and thus discover its Guards.
 
 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.
+in [Section 1.3.5](#135-passive-application-layer-traffic-patterns), 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\]][refs] in the
 references.
 
-Tor deployed a defense for this oracle in the [\[DNSORACLE\]][refs] tickets, to
+Effectively, these oracles provide a low resolution observation of the other
+end of a website traffic packet capture.
+
+Tor deployed a defense for its DNS oracle in the [\[DNSORACLE\]][refs] 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.
@@ -658,92 +1025,10 @@ under either current C-Tor, or future arti-relay circumstances.
 |----|----|
 | **Solution**: | 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:**
-
-| **Characteristic** | **Information** |
-|----|-----|
-| **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**:| Connection tuple times and byte counts |
-| **Signal is injected**: | Created by using the network |
-| **Signal is observed**: | At ISP of everything that is using the network |
-
-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\]][refs].
-
-Tor has a padding mechanism to reduce the resolution of this data (see Section
-2 of [\[PADDING_SPEC\]][refs]), 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\]][refs].
-
-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\]][refs]. 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.
-
-**Mitigation Plan**:
-
-| **Action** | **Details** |
-|----|----|
-| **Solution**: | 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 |
+| **Funding**: | Any further fixes are covered by Project 112 |
 
 
-### 1.3.2. Active Traffic Manipulation Covert Channels
+### 1.3.4. Active Traffic Manipulation Covert Channels
 
 **At a glance:**
 
@@ -774,11 +1059,11 @@ 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.
+time, which can be seen in netflow logs, to enable netflow deanonymization of
+a service.
 
 For clients, this covert channel typically is only effective after the
-adversary suspects an individual, for confirmation of their suspicion, or
-after Guard Discovery.
+[adversary suspects an individual](#24-application-layer-confirmation), for confirmation of their suspicion, or after Guard Discovery.
 
 Examples of this class of covert channel include:
   - Application-layer manipulation (AJAX)
@@ -797,7 +1082,7 @@ Examples of this class of covert channel include:
 | **Funding**: | Not explicitly funded |
 
 
-### 1.3.3. Passive Application-Layer Traffic Patterns
+### 1.3.5. Passive Application-Layer Traffic Patterns
 
 **At a glance:**
 
@@ -918,10 +1203,10 @@ right now.
 |----|----|
 | **Solution**: | Application layer solutions ([\[ALPACA\]][refs], 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 |
+| **Funding**: | Padding machine and simulator port to arti are funded via Project 112 |
 
 
-### 1.3.4. Protocol or Application Linkability
+### 1.3.6. Protocol or Application Linkability
 
 **At a glance:**
 
@@ -977,7 +1262,7 @@ seems like not so much.
 | **Funding**: | Not explicitly funded |
 
 
-### 1.3.5. Latency Measurement
+### 1.3.7. Latency Measurement
 
 **At a glance:**
 
@@ -1033,7 +1318,7 @@ 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
+bitflipping technique from [Section 1.1.2](#112-end-to-end-cell-header-manipulation). 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.
 
@@ -1042,8 +1327,7 @@ 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
+A similar, motivated adversary could use any of the covert channels in [Section 1.1](#11-highly-severe-internal-covert-channel-vectors), 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
@@ -1061,8 +1345,8 @@ 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
+combine [Adversary-Induced Circuit Creation](#122-adversary-induced-circuit-creation) with a circuit-based
+info leak ([1.1.3](#113-dropped-cells), [1.2.3](#123-handshakes-with-unique-traffic-patterns), or [1.3.4](#134-active-traffic-manipulation-covert-channels)), 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
@@ -1096,7 +1380,7 @@ this case.
 
 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.
+[1.3.4](#134-active-traffic-manipulation-covert-channels).
 
 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
@@ -1138,6 +1422,9 @@ infrequently.
   but some similar traffic pattern or behavior elsewhere matches the traffic
   pattern of their info leak vector.
 
+**Global Adversary:**
+  An adversary that can observe all entrances and exits of the Tor network.
+
 **Guard Discovery:**
   The ability of an adversary to determine the Guard in use by a service or
   client.
@@ -1146,6 +1433,10 @@ infrequently.
   The ability of a covert channel to reliably encode a unique identifier,
   such as an IP address, without error.
 
+**Local Adversary:**
+  An adversary that can observe only fractions of the Tor network
+  entrance and exit capacity.
+
 **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
@@ -1156,6 +1447,15 @@ infrequently.
   compromised relays, by destroying circuits and/or TLS connections
   whose paths are not sufficiently compromised.
 
+**Traffic Analysis (Tor Threat Model Definition):**
+  Attacks where an adversary gains information or influences where they
+  need to observe traffic, in order to maximize the utility of its `c/n`
+  observation capability.
+
+**Traffic Confirmation (Tor Threat Model Definition):**
+  These are attacks where an adversary observes both ends of a communication
+  and confirms that communication is taking place.
+
 
 # Acknowledgments:
 
@@ -1247,12 +1547,27 @@ Hopper, Rob Jansen, Nick Mathewson, Tobias Pulls, and Florentin Rochet.
 \[RELAY_EARLY\]
   - <https://blog.torproject.org/tor-security-advisory-relay-early-traffic-confirmation-attack/>
 
-\[RFINGERPRINT\]
+\[ROBFINGERPRINT\]
   - <https://www.usenix.org/conference/usenixsecurity23/presentation/shen-meng>
 
 \[SBWS\]
   - <https://tpo.pages.torproject.net/network-health/sbws/how_works.html>
 
+\[SNIPER\]
+  - <https://www.robgjansen.com/publications/sniper-ndss2014.pdf>
+  - <https://dl.acm.org/doi/10.1145/3589334.3645591>
+
+\[TRAPPING_TOR\]
+  - <https://www.csit.carleton.ca/wshi/wp-content/uploads/2022/09/An_Anonymity_Vulnerability_in_Tor.pdf>
+
+\[TOR_DESIGN\]
+  - <https://svn-archive.torproject.org/svn/projects/design-paper/tor-design.html>
+
+\[TOR_DESIGN_UPDATES\]
+  - <https://blog.torproject.org/top-changes-tor-2004-design-paper-part-1/>
+  - <https://blog.torproject.org/top-changes-tor-2004-design-paper-part-2/>
+  - <https://blog.torproject.org/top-changes-tor-2004-design-paper-part-3/>
+
 \[WFLIVE\]
   - <https://www.usenix.org/system/files/sec22-cherubin.pdf>
 
diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md
index e731395c..620ac939 100644
--- a/proposals/BY_INDEX.md
+++ b/proposals/BY_INDEX.md
@@ -261,7 +261,7 @@ Below are a list of proposals sorted by their proposal number.  See
 * [`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.md`](/proposals/344-protocol-info-leaks.md): Prioritizing Protocol Information Leaks in Tor \[OPEN\]
+* [`344-protocol-info-leaks.md`](/proposals/344-protocol-info-leaks.md): Information Leak Hazards for Tor Implementations \[OPEN\]
 * [`345-specs-in-mdbook.md`](/proposals/345-specs-in-mdbook.md): Migrating the tor specifications to mdbook \[CLOSED\]
 * [`346-protovers-again.md`](/proposals/346-protovers-again.md): Clarifying and extending the use of protocol versioning \[OPEN\]
 * [`347-domain-separation.md`](/proposals/347-domain-separation.md): Domain separation for certificate signing keys \[OPEN\]
diff --git a/proposals/BY_STATUS.md b/proposals/BY_STATUS.md
index 0d12c065..737e1f73 100644
--- a/proposals/BY_STATUS.md
+++ b/proposals/BY_STATUS.md
@@ -37,7 +37,7 @@ for discussion.
 * [`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.md`](/proposals/344-protocol-info-leaks.md): Prioritizing Protocol Information Leaks in Tor
+* [`344-protocol-info-leaks.md`](/proposals/344-protocol-info-leaks.md): Information Leak Hazards for Tor Implementations
 * [`346-protovers-again.md`](/proposals/346-protovers-again.md): Clarifying and extending the use of protocol versioning
 * [`347-domain-separation.md`](/proposals/347-domain-separation.md): Domain separation for certificate signing keys
 * [`348-udp-app-support.md`](/proposals/348-udp-app-support.md): UDP Application Support in Tor
diff --git a/proposals/SUMMARY.md b/proposals/SUMMARY.md
index 2865d934..6d455606 100644
--- a/proposals/SUMMARY.md
+++ b/proposals/SUMMARY.md
@@ -254,7 +254,7 @@
  - [`341-better-oos`](./341-better-oos.md): A better algorithm for out-of-sockets eviction (OPEN)
  - [`342-decouple-hs-interval`](./342-decouple-hs-interval.md): Decoupling hs_interval and SRV lifetime (DRAFT)
  - [`343-rend-caa`](./343-rend-caa.txt): CAA Extensions for the Tor Rendezvous Specification (OPEN)
- - [`344-protocol-info-leaks`](./344-protocol-info-leaks.md): Prioritizing Protocol Information Leaks in Tor (OPEN)
+ - [`344-protocol-info-leaks`](./344-protocol-info-leaks.md): Information Leak Hazards for Tor Implementations (OPEN)
  - [`345-specs-in-mdbook`](./345-specs-in-mdbook.md): Migrating the tor specifications to mdbook (CLOSED)
  - [`346-protovers-again`](./346-protovers-again.md): Clarifying and extending the use of protocol versioning (OPEN)
  - [`347-domain-separation`](./347-domain-separation.md): Domain separation for certificate signing keys (OPEN)
-- 
GitLab


From e65e55bcab0ebcdf97daa3380a99d956a92e3807 Mon Sep 17 00:00:00 2001
From: Mike Perry <mikeperry-git@torproject.org>
Date: Tue, 1 Apr 2025 22:14:17 +0000
Subject: [PATCH 2/2] Prop344: Readability fixes from Alex's review

---
 proposals/344-protocol-info-leaks.md | 99 ++++++++++++++--------------
 1 file changed, 50 insertions(+), 49 deletions(-)

diff --git a/proposals/344-protocol-info-leaks.md b/proposals/344-protocol-info-leaks.md
index a188c244..49fa70d8 100644
--- a/proposals/344-protocol-info-leaks.md
+++ b/proposals/344-protocol-info-leaks.md
@@ -57,13 +57,14 @@ attacks that are known to have been performed against Tor in [Section
 2](#2-attack-examples), 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](#2-attack-examples) 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 we are not aware of any direct
-evidence of this occurring with respect to Tor cases. Keep your eyes peeled...
+We are interested in [hearing from](https://www.torproject.org/contact/)
+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](#2-attack-examples) 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 we
+are not aware of any direct evidence of this occurring with respect to Tor
+cases. Keep your eyes peeled...
 
 ## 0.1. Background: Gaps in Tor's Original Threat Model
 
@@ -152,12 +153,12 @@ are: "Highly Severe Covert Channels", "Zero-Click Behavior Manipulation
 Primitives", and "Augmented Observation Primitives".
 
 The first category allows malicious relays to communicate their presence in a
-circuit prior to any application traffic, which yields dragnet deanonymization
-attacks by itself. The second category are properties of Tor's Protocol and
-client behavior that can be used to assist attacks that can lead to arbitrary
-deanonymization. The final category covers information leaks that enable a
-local adversary to approximate a global adversary, typically assisted by
-earlier vectors, or outside information, to improve confirmation accuracy.
+circuit prior to any application traffic, which yields full-take
+deanonymization attacks by itself. The second category are properties of Tor's
+Protocol and client behavior that can be used to assist attacks that can lead
+to arbitrary deanonymization. The final category covers information leaks that
+enable a local adversary to approximate a global adversary, typically assisted
+by earlier vectors, or outside information, to improve confirmation accuracy.
 
 For each vector, we provide a brief "at-a-glance" summary table, which
 includes a ballpark estimate of Accuracy in terms of False Positives (FP) and
@@ -202,16 +203,16 @@ only to compromised Exits. This removes both `c/n` factors, fully
 deanonymizing all users who are subject to this censorship firewall. In these
 specific circumstances, Tor is actually less secure than a 1-hop VPN.
 
-> This style of censorship-based deanonymization attack was first academically
-> published in [\[TRAPPING_TOR\]][refs], and it also includes a covert
-> channel. However, their covert channel (stream correlation) does not satisfy
-> the first requirement of this section, because it relies on streams already
-> sending data. In practice, this means that targeted users would notice their
-> connections were repeatedly being terminated mid-download, and would have
-> great difficulty actually using Tor to download anything. The covert
-> channels in this section, by contrast, enable closing circuits *before*
-> application traffic begins, thus making them invisible to targeted users,
-> other than as a higher circuit failure rate.
+This style of censorship-based deanonymization attack was first academically
+published in [\[TRAPPING_TOR\]][refs], and it also includes a covert
+channel. However, their covert channel (stream correlation) does not satisfy
+the first requirement of this section, because it relies on streams already
+sending data. In practice, this means that targeted users would notice their
+connections were repeatedly being terminated mid-download, and would have
+great difficulty actually using Tor to download anything. The covert
+channels in this section, by contrast, enable closing circuits *before*
+application traffic begins, thus making them invisible to targeted users,
+other than as a higher circuit failure rate.
 
 ### 1.1.1. Cryptographic Tagging
 
@@ -219,7 +220,7 @@ specific circumstances, Tor is actually less secure than a 1-hop VPN.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=0, FN=0 |
+| **Accuracy**: | False Positive=0, False Negative=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) |
@@ -290,7 +291,7 @@ adversary also ends up in the HSDIR position, for deanonymization.
 
 | **Action** | **Details** |
 |----|----|
-| **Solution**: | Path Bias Exit Usage Counter; Counter Galois Onion (CGO) (Forthcoming update to Prop#308). |
+| **Solution**: | Path Bias Exit Usage Counter; [Prop359: Counter Galois Onion](https://spec.torproject.org/proposals/359) |
 | **Status**: | Unfixed (Current PathBias detector is error-prone under DDoS) |
 | **Funding**: | CGO explicitly funded via Project 112 |
 
@@ -301,7 +302,7 @@ adversary also ends up in the HSDIR position, for deanonymization.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=0, FN=0 |
+| **Accuracy**: | False Positive=0, False Negative=0 |
 | **Requires**: | Malicious or compromised Guard, at least one exit |
 | **Impact**: | Full deanonymization (path bias, identifier transmission) |
 | **Path Bias**: | Full route capture is trivial |
@@ -351,13 +352,13 @@ somewhat surprising that the [FBI used this attack](#21-cmu-tagging-attack)
 before cryptographic tagging, but perhaps that was just a lucky coincidence of
 opportunity.
 
-The CGO proposal (an updated form of Prop#308) will eliminate the ability of
-Guards to alter cell commands via a MAC, but Exits, HSDir, and Intro Point
-relays will still be able to make use of the vector towards the client, if it
-is not mitigated at the client. Additionally, this MAC will not prevent this
-covert channel from being used all the way from an onion client to an onion
-service, or vice-versa, on a rend circuit, especially one with a malicious RP
-relay.
+[Proposal 359](https://spec.torproject.org/proposals/359) will eliminate the
+ability of Guards to alter cell commands via a MAC, but Exits, HSDir, and
+Intro Point relays will still be able to make use of the vector towards the
+client, if it is not mitigated at the client. Additionally, this MAC will not
+prevent this covert channel from being used all the way from an onion client
+to an onion service, or vice-versa, on a rend circuit, especially one with a
+malicious RP relay.
 
 **Mitigation Plan**:
 
@@ -374,7 +375,7 @@ relay.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=0, FN=0 |
+| **Accuracy**: | False Positive=0, False Negative=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 |
@@ -397,8 +398,8 @@ discarded by a Tor client. These include:
   - Onion descriptor-appended junk
 
 Additionally, clients can send arbitrary relay commands to onion services, which includes the above set, plus:
-  - RELAY_BEGIN to invalid addrs/ports
-  - RELAY_BEGIN to reused stream-ids
+  - `RELAY_BEGIN` to invalid addrs/ports
+  - `RELAY_BEGIN` to reused stream-ids
   - Relay commands normally reserved for relays or exits
   - Unsupported optimistic data
 
@@ -482,7 +483,7 @@ are not inherent to low-latency mix networks in general.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=0, FN=0 |
+| **Accuracy**: | False Positive=0, False Negative=0 |
 | **Requires**: | Local ISP or Censorship Firewall, at least one Guard |
 | **Impact**: | Guard choice control |
 | **Path Bias**: | Provides control of Guard, which can perform previous attacks |
@@ -542,7 +543,7 @@ client guards in a set.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=high, FN=high |
+| **Accuracy**: | False Positive=high, False Negative=high |
 | **Requires**: | Onion service activity, or malicious exit |
 | **Impact**: | Guard discovery |
 | **Path Bias**: | Repeated circuits eventually provide the desired path |
@@ -640,7 +641,7 @@ network. The circuit dirty timeout issue remains unaddressed.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=near-zero, FN=near-zero |
+| **Accuracy**: | False Positive=near-zero, False Negative=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) |
@@ -708,7 +709,7 @@ practical. Effectively, it functions as a kind of oracle in this case (see
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=0, FN=0 |
+| **Accuracy**: | False Positive=0, False Negative=0 |
 | **Requires**: | Running relays in the network |
 | **Impact**: | Clients migrate to malicious relays |
 | **Path Bias**: | May provide adversary with control of target's Guard or HSDir |
@@ -736,7 +737,7 @@ flag itself.
 
 | **Action** | **Details** |
 |----|----|
-| **Solution**: | C-Tor has an oom killer to free memory under pressure; Circuits with excessive queues are force-closed at relays |
+| **Solution**: | C-Tor has an OOM killer to free memory under pressure; Circuits with excessive queues are force-closed at relays |
 | **Status**: | C-Tor OOM killer may have edge cases |
 | **Funding**: | Fixes covered by Project 112 |
 
@@ -746,7 +747,7 @@ flag itself.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=high, FN=high |
+| **Accuracy**: | False Positive=high, False Negative=high |
 | **Requires**: | Running relays in the network |
 | **Impact**: | Additional traffic towards malicious relays |
 | **Path Bias**: | Bandwidth lying can make up for circuit rejection |
@@ -841,7 +842,7 @@ for both attacks and defenses.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=high; FN=0 (FN=medium with incomplete vantage point set) |
+| **Accuracy**: | False Positive=high; False Negative=0 (False Negative=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 |
@@ -920,7 +921,7 @@ combination with Guard Discovery.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=low, FN=high |
+| **Accuracy**: | False Positive=low, False Negative=high |
 | **Requires**: | Some mechanism to bias or inflate reported relay metrics |
 | **Impact**: | Guard discovery |
 | **Path Bias**: | Potentially relevant, depending on type of leak |
@@ -962,7 +963,7 @@ in use by onion services, and thus discover its Guards.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=medium, FN=0 (for unpopular sites: FP=0, FN=0) |
+| **Accuracy**: | False Positive=medium, False Negative=0 (for unpopular sites: False Positive=0, False Negative=0) |
 | **Requires**: | Probing relay DNS cache |
 | **Impact**: | Assists Website Traffic Fingerprinting; Domain Usage Analytics |
 | **Path Bias**: | Not Possible |
@@ -1034,7 +1035,7 @@ under either current C-Tor, or future arti-relay circumstances.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=medium, FN=low |
+| **Accuracy**: | False Positive=medium, False Negative=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 |
@@ -1088,7 +1089,7 @@ Examples of this class of covert channel include:
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=medium, FN=medium |
+| **Accuracy**: | False Positive=medium, False Negative=medium |
 | **Requires**: | Compromised Guard (external monitoring increases FP+FN rate) |
 | **Impact**: | Links client and destination activity (ie: deanonymization with logs) |
 | **Path Bias**: | Not Possible |
@@ -1212,7 +1213,7 @@ right now.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=0, FN=0 |
+| **Accuracy**: | False Positive=0, False Negative=0 |
 | **Requires**: | Compromised Exit; Traffic Observation; Hostile Website |
 | **Impact**: | Anonymity Set Reduction |
 | **Path Bias**: | Not Possible |
@@ -1268,7 +1269,7 @@ seems like not so much.
 
 | **Characteristic** | **Information** |
 |----|-----|
-| **Accuracy**: | FP=high, FN=high |
+| **Accuracy**: | False Positive=high, False Negative=high |
 | **Requires**: | Onion service, or malicious Exit |
 | **Impact**: | Anonymity Set Reduction/Rough geolocation of services |
 | **Path Bias**: | Possible exacerbating factor |
-- 
GitLab