Remove tables of contents from several specs.

These are outdated and redundant.

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