From 3c829ac5b86c02ec025c5970b4a1045937da2189 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Sat, 14 Oct 2023 17:12:15 -0400 Subject: Remove tables of contents from several specs. These are outdated and redundant. --- spec/padding-spec-intro.md | 29 +-------------- spec/pt-spec-intro.md | 28 ++------------- spec/rend-spec-v3-intro.md | 90 +--------------------------------------------- spec/srv-spec-intro.md | 46 ++---------------------- spec/tor-spec-intro.md | 81 +---------------------------------------- 5 files changed, 7 insertions(+), 267 deletions(-) diff --git a/spec/padding-spec-intro.md b/spec/padding-spec-intro.md index b9172db..5ab11f8 100644 --- a/spec/padding-spec-intro.md +++ b/spec/padding-spec-intro.md @@ -1,4 +1,4 @@ -Tor Padding Specification +# Tor Padding Specification Mike Perry, George Kadianakis @@ -10,30 +10,3 @@ various traffic patterns from external and internal observers. Other implementations MAY take other approaches, but implementors should be aware of the anonymity and load-balancing implications of their choices. -```text - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - RFC 2119. - -Table of Contents - - 1. Overview - 2. Connection-level padding - 2.1. Background - 2.2. Implementation - 2.3. Padding Cell Timeout Distribution Statistics - 2.4. Maximum overhead bounds - 2.5. Reducing or Disabling Padding via Negotiation - 2.6. Consensus Parameters Governing Behavior - 3. Circuit-level padding - 3.1. Circuit Padding Negotiation - 3.2. Circuit Padding Machine Message Management - 3.3. Obfuscating client-side onion service circuit setup - 3.3.1. Common general circuit construction sequences - 3.3.2. Client-side onion service introduction circuit obfuscation - 3.3.3. Client-side rendezvous circuit hiding - 3.3.4. Circuit setup machine overhead - 3.4. Circuit padding consensus parameters - A. Acknowledgments -``` diff --git a/spec/pt-spec-intro.md b/spec/pt-spec-intro.md index 1b4555e..83ff5e9 100644 --- a/spec/pt-spec-intro.md +++ b/spec/pt-spec-intro.md @@ -1,6 +1,6 @@ -Pluggable Transport Specification (Version 1) +# Pluggable Transport Specification (Version 1) -Abstract +## Abstract Pluggable Transports (PTs) are a generic mechanism for the rapid development and deployment of censorship circumvention, @@ -11,27 +11,3 @@ This document specifies the sub-process startup, shutdown, and inter-process communication mechanisms required to utilize PTs. -Table of Contents - -```text - 1. Introduction - 1.1. Requirements Notation - 2. Architecture Overview - 3. Specification - 3.1. Pluggable Transport Naming - 3.2. Pluggable Transport Configuration Environment Variables - 3.2.1. Common Environment Variables - 3.2.2. Pluggable Transport Client Environment Variables - 3.2.3. Pluggable Transport Server Environment Variables - 3.3. Pluggable Transport To Parent Process Communication - 3.3.1. Common Messages - 3.3.2. Pluggable Transport Client Messages - 3.3.3. Pluggable Transport Server Messages - 3.4. Pluggable Transport Shutdown - 3.5. Pluggable Transport Client Per-Connection Arguments - 4. Anonymity Considerations - 5 References - 6. Acknowledgments - Appendix A. Example Client Pluggable Transport Session - Appendix B. Example Server Pluggable Transport Session -``` diff --git a/spec/rend-spec-v3-intro.md b/spec/rend-spec-v3-intro.md index 78efe6a..47e65aa 100644 --- a/spec/rend-spec-v3-intro.md +++ b/spec/rend-spec-v3-intro.md @@ -1,97 +1,9 @@ -Tor Rendezvous Specification - Version 3 +# Tor Rendezvous Specification - Version 3 This document specifies how the hidden service version 3 protocol works. This text used to be proposal 224-rend-spec-ng.txt. -Table of contents: - -```text - 0. Hidden services: overview and preliminaries. - 0.1. Improvements over previous versions. - 0.2. Notation and vocabulary - 0.3. Cryptographic building blocks - 0.4. Protocol building blocks [BUILDING-BLOCKS] - 0.5. Assigned relay cell types - 0.6. Acknowledgments - 1. Protocol overview - 1.1. View from 10,000 feet - 1.2. In more detail: naming hidden services [NAMING] - 1.3. In more detail: Access control [IMD:AC] - 1.4. In more detail: Distributing hidden service descriptors. [IMD:DIST] - 1.5. In more detail: Scaling to multiple hosts - 1.6. In more detail: Backward compatibility with older hidden service - 1.7. In more detail: Keeping crypto keys offline - 1.8. In more detail: Encryption Keys And Replay Resistance - 1.9. In more detail: A menagerie of keys - 1.9.1. In even more detail: Client authorization [CLIENT-AUTH] - 2. Generating and publishing hidden service descriptors [HSDIR] - 2.1. Deriving blinded keys and subcredentials [SUBCRED] - 2.2. Locating, uploading, and downloading hidden service descriptors - 2.2.1. Dividing time into periods [TIME-PERIODS] - 2.2.2. When to publish a hidden service descriptor [WHEN-HSDESC] - 2.2.3. Where to publish a hidden service descriptor [WHERE-HSDESC] - 2.2.4. Using time periods and SRVs to fetch/upload HS descriptors - 2.2.5. Expiring hidden service descriptors [EXPIRE-DESC] - 2.2.6. URLs for anonymous uploading and downloading - 2.3. Publishing shared random values [PUB-SHAREDRANDOM] - 2.3.1. Client behavior in the absence of shared random values - 2.3.2. Hidden services and changing shared random values - 2.4. Hidden service descriptors: outer wrapper [DESC-OUTER] - 2.5. Hidden service descriptors: encryption format [HS-DESC-ENC] - 2.5.1. First layer of encryption [HS-DESC-FIRST-LAYER] - 2.5.1.1. First layer encryption logic - 2.5.1.2. First layer plaintext format - 2.5.1.3. Client behavior - 2.5.1.4. Obfuscating the number of authorized clients - 2.5.2. Second layer of encryption [HS-DESC-SECOND-LAYER] - 2.5.2.1. Second layer encryption keys - 2.5.2.2. Second layer plaintext format - 2.5.3. Deriving hidden service descriptor encryption keys [HS-DESC-ENCRYPTION-KEYS] - 3. The introduction protocol [INTRO-PROTOCOL] - 3.1. Registering an introduction point [REG_INTRO_POINT] - 3.1.1. Extensible ESTABLISH_INTRO protocol. [EST_INTRO] - 3.1.1.1. Denial-of-Server Defense Extension. [EST_INTRO_DOS_EXT] - 3.1.2. Registering an introduction point on a legacy Tor node [LEGACY_EST_INTRO] - 3.1.3. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] - 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1] - 3.2.1. INTRODUCE1 cell format [FMT_INTRO1] - 3.2.2. INTRODUCE_ACK cell format. [INTRO_ACK] - 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2] - 3.3.1. Introduction handshake encryption requirements [INTRO-HANDSHAKE-REQS] - 3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA] - 3.4. Authentication during the introduction phase. [INTRO-AUTH] - 3.4.1. Ed25519-based authentication. - 4. The rendezvous protocol - 4.1. Establishing a rendezvous point [EST_REND_POINT] - 4.2. Joining to a rendezvous point [JOIN_REND] - 4.2.1. Key expansion - 4.3. Using legacy hosts as rendezvous points - 5. Encrypting data between client and host - 6. Encoding onion addresses [ONIONADDRESS] - 7. Open Questions: - --1. Draft notes -``` - This document describes a proposed design and specification for hidden services in Tor version 0.2.5.x or later. It's a replacement for the current rend-spec.txt, rewritten for clarity and for improved design. - -Look for the string "TODO" below: it describes gaps or uncertainties -in the design. - -Change history: - -2013-11-29: Proposal first numbered. Some TODO and XXX items remain. - -2014-01-04: Clarify some unclear sections. - -2014-01-21: Fix a typo. - -```text - 2014-02-20: Move more things to the revised certificate format in the - new updated proposal 220. - - 2015-05-26: Fix two typos. -``` diff --git a/spec/srv-spec-intro.md b/spec/srv-spec-intro.md index fecb4f8..ce15a85 100644 --- a/spec/srv-spec-intro.md +++ b/spec/srv-spec-intro.md @@ -1,49 +1,7 @@ -Tor Shared Random Subsystem Specification +# Tor Shared Random Subsystem Specification This document specifies how the commit-and-reveal shared random subsystem of Tor works. This text used to be proposal 250-commit-reveal-consensus.txt. -Table Of Contents: -```text - 1. Introduction - 1.1. Motivation - 1.2. Previous work - 2. Overview - 2.1. Introduction to our commit-and-reveal protocol - 2.2. Ten thousand feet view of the protocol - 2.3. How we use the consensus [CONS] - 2.3.1. Inserting Shared Random Values in the consensus - 2.4. Persistent State of the Protocol [STATE] - 2.5. Protocol Illustration - 3. Protocol - 3.1 Commitment Phase [COMMITMENTPHASE] - 3.1.1. Voting During Commitment Phase - 3.1.2. Persistent State During Commitment Phase [STATECOMMIT] - 3.2 Reveal Phase - 3.2.1. Voting During Reveal Phase - 3.2.2. Persistent State During Reveal Phase [STATEREVEAL] - 3.3. Shared Random Value Calculation At 00:00UTC - 3.3.1. Shared Randomness Calculation [SRCALC] - 3.4. Bootstrapping Procedure - 3.5. Rebooting Directory Authorities [REBOOT] - 4. Specification [SPEC] - 4.1. Voting - 4.1.1. Computing commitments and reveals [COMMITREVEAL] - 4.1.2. Validating commitments and reveals [VALIDATEVALUES] - 4.1.4. Encoding commit/reveal values in votes [COMMITVOTE] - 4.1.5. Shared Random Value [SRVOTE] - 4.2. Encoding Shared Random Values in the consensus [SRCONSENSUS] - 4.3. Persistent state format [STATEFORMAT] - 5. Security Analysis - 5.1. Security of commit-and-reveal and future directions - 5.2. Predicting the shared random value during reveal phase - 5.3. Partition attacks - 5.3.1. Partition attacks during commit phase - 5.3.2. Partition attacks during reveal phase - 6. Discussion - 6.1. Why the added complexity from proposal 225? - 6.2. Why do you do a commit-and-reveal protocol in 24 rounds? - 6.3. Why can't we recover if the 00:00UTC consensus fails? - 7. Acknowledgements -``` + diff --git a/spec/tor-spec-intro.md b/spec/tor-spec-intro.md index 185d852..a81e1b9 100644 --- a/spec/tor-spec-intro.md +++ b/spec/tor-spec-intro.md @@ -1,83 +1,4 @@ -Tor Protocol Specification - -```text - Roger Dingledine - Nick Mathewson - -Table of Contents - - 0. Preliminaries - 0.1. Notation and encoding - 0.2. Security parameters - 0.3. Ciphers - 0.4. A bad hybrid encryption algorithm, for legacy purposes - 1. System overview - 1.1. Keys and names - 2. Connections - 2.1. Picking TLS ciphersuites - 2.2. TLS security considerations - 3. Cell Packet format - 4. Negotiating and initializing connections - 4.1. Negotiating versions with VERSIONS cells - 4.2. CERTS cells - 4.3. AUTH_CHALLENGE cells - 4.4. AUTHENTICATE cells - 4.4.1. Link authentication type 1: RSA-SHA256-TLSSecret - 4.4.2. Link authentication type 3: Ed25519-SHA256-RFC5705 - 4.5. NETINFO cells - 5. Circuit management - 5.1. CREATE and CREATED cells - 5.1.1. Choosing circuit IDs in create cells - 5.1.2. EXTEND and EXTENDED cells - 5.1.3. The "TAP" handshake - 5.1.4. The "ntor" handshake - 5.1.4.1. The "ntor-v3" handshake. - 5.1.5. CREATE_FAST/CREATED_FAST cells - 5.1.6. Additional data in CREATE/CREATED cells - 5.2. Setting circuit keys - 5.2.1. KDF-TOR - 5.2.2. KDF-RFC5869 - 5.3. Creating circuits - 5.3.1. Canonical connections - 5.4. Tearing down circuits - 5.5. Routing relay cells - 5.5.1. Circuit ID Checks - 5.5.2. Forward Direction - 5.5.2.1. Routing from the Origin - 5.5.2.2. Relaying Forward at Onion Routers - 5.5.3. Backward Direction - 5.5.3.1. Relaying Backward at Onion Routers - 5.5.4. Routing to the Origin - 5.6. Handling relay_early cells - 6. Application connections and stream management - 6.1. Relay cells - 6.1.1. Calculating the 'Digest' field - 6.2. Opening streams and transferring data - 6.2.1. Opening a directory stream - 6.3. Closing streams - 6.4. Remote hostname lookup - 7. Flow control - 7.1. Link throttling - 7.2. Link padding - 7.3. Circuit-level flow control - 7.3.1. SENDME Cell Format - 7.4. Stream-level flow control - 8. Handling resource exhaustion - 8.1. Memory exhaustion - 9. Subprotocol versioning - 9.1. "Link" - 9.2. "LinkAuth" - 9.3. "Relay" - 9.4. "HSIntro" - 9.5. "HSRend" - 9.6. "HSDir" - 9.7. "DirCache" - 9.8. "Desc" - 9.9. "Microdesc" - 9.10. "Cons" - 9.11. "Padding" - 9.12. "FlowCtrl" -``` +# Tor Protocol Specification Note: This document aims to specify Tor as currently implemented, though it may take it a little time to become fully up to date. Future versions of Tor -- cgit v1.2.3-54-g00ecf