As part of Sponsor 112, Tor has an objective to address covert channels that malicious relays can use to deanonymize users. This proposal lays the groundwork by categorizing these issues, and prioritizes them according to their severity. Subsequent proposals will deal with specific solutions.

I am posting just the intro section of this proposal here. The full proposal is at: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-pro...

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

The remainder of this proposal can be read at: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/344-pro...