8 files changed, 59 insertions, 59 deletions
diff --git a/spec/rend-spec-v3/deriving-keys.md b/spec/rend-spec-v3/deriving-keys.md
index 201fc92..cbf62fe 100644
--- a/spec/rend-spec-v3/deriving-keys.md
+++ b/spec/rend-spec-v3/deriving-keys.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-2.1"></a>
 
-## Deriving blinded keys and subcredentials \[SUBCRED\]
+## Deriving blinded keys and subcredentials {#SUBCRED}
 
 In each time period (see \[TIME-PERIODS\] for a definition of time
 periods), a hidden service host uses a different blinded private key
@@ -58,7 +58,7 @@ Which Tor servers hosts a hidden service depends on:
 
 <a id="rend-spec-v3.txt-2.2.1"></a>
 
-### Dividing time into periods \[TIME-PERIODS\]
+### Dividing time into periods {#TIME-PERIODS}
 
 To prevent a single set of hidden service directory from becoming a
 target by adversaries looking to permanently censor a hidden service,
@@ -90,7 +90,7 @@ after the epoch, at 2016-04-12 12:00 UTC, and ended at 16904*1440*60 +
 
 <a id="rend-spec-v3.txt-2.2.2"></a>
 
-### When to publish a hidden service descriptor \[WHEN-HSDESC\]
+### When to publish a hidden service descriptor {#WHEN-HSDESC}
 
 Hidden services periodically publish their descriptor to the responsible
 HSDirs. The set of responsible HSDirs is determined as specified in
@@ -104,7 +104,7 @@ descriptor again to the responsible HSDirs for that time period.
 
 <a id="rend-spec-v3.txt-2.2.2.1"></a>
 
-#### Overlapping descriptors
+#### Overlapping descriptors {#OVERLAPPING-DESCS}
 
 Hidden services need to upload multiple descriptors so that they can be
 reachable to clients with older or newer consensuses than them. Services
@@ -125,7 +125,7 @@ achieved.
 
 <a id="rend-spec-v3.txt-2.2.3"></a>
 
-### Where to publish a hidden service descriptor \[WHERE-HSDESC\]
+### Where to publish a hidden service descriptor {#WHERE-HSDESC}
 
 This section specifies how the HSDir hash ring is formed at any given
 time. Whenever a time value is needed (e.g. to get the current time period
@@ -190,7 +190,7 @@ choosing the spread for a replica.
 
 <a id="rend-spec-v3.txt-2.2.4"></a>
 
-### Using time periods and SRVs to fetch/upload HS descriptors \[FETCHUPLOADDESC\]
+### Using time periods and SRVs to fetch/upload HS descriptors {#FETCHUPLOADDESC}
 
 Hidden services and clients need to make correct use of time periods (TP)
 and shared random values (SRVs) to successfully fetch and upload
@@ -228,7 +228,7 @@ Let's start with an illustration of the system:
 
 <a id="rend-spec-v3.txt-2.2.4.1"></a>
 
-#### Client behavior for fetching descriptors \[CLIENTFETCH\]
+#### Client behavior for fetching descriptors {#CLIENTFETCH}
 
 And here is how clients use TPs and SRVs to fetch descriptors:
 
@@ -258,7 +258,7 @@ after SRV#2, it will still use TP#1 and SRV#1.
 
 <a id="rend-spec-v3.txt-2.2.4.2"></a>
 
-#### Service behavior for uploading descriptors \[SERVICEUPLOAD\]
+#### Service behavior for uploading descriptors {#SERVICEUPLOAD}
 
 As discussed above, services maintain two active descriptors at any time. We
 call these the "first" and "second" service descriptors. Services rotate
@@ -272,7 +272,7 @@ values based on their position in the graph above. Here is the logic:
 
 <a id="rend-spec-v3.txt-2.2.4.2.1"></a>
 
-##### First descriptor upload logic \[FIRSTDESCUPLOAD\]
+##### First descriptor upload logic {#FIRSTDESCUPLOAD}
 
 Here is the service logic for uploading its first descriptor:
 
@@ -308,7 +308,7 @@ first descriptor using TP#1 and SRV#1.
 
 <a id="rend-spec-v3.txt-2.2.4.2.2"></a>
 
-##### Second descriptor upload logic \[SECONDDESCUPLOAD\]
+##### Second descriptor upload logic {#SECONDDESCUPLOAD}
 
 Here is the service logic for uploading its second descriptor:
 
@@ -368,7 +368,7 @@ necessary client credentials (for decrypting the second layer).
 
 <a id="rend-spec-v3.txt-2.2.5"></a>
 
-### Expiring hidden service descriptors \[EXPIRE-DESC\]
+### Expiring hidden service descriptors {#EXPIRE-DESC}
 
 Hidden services set their descriptor's "descriptor-lifetime" field to 180
 minutes (3 hours). Hidden services ensure that their descriptor will remain
@@ -381,7 +381,7 @@ the time period has changed).
 
 <a id="rend-spec-v3.txt-2.2.6"></a>
 
-### URLs for anonymous uploading and downloading
+### URLs for anonymous uploading and downloading {#urls}
 
 Hidden service descriptors conforming to this specification are uploaded
 with an HTTP POST request to the URL `/tor/hs/<version>/publish` relative to
@@ -395,7 +395,7 @@ anything else.
 
 <a id="rend-spec-v3.txt-2.2.7"></a>
 
-### Client-side validation of onion addresses
+### Client-side validation of onion addresses {#addr-validation}
 
 When a Tor client receives a prop224 onion address from the user, it
 MUST first validate the onion address before attempting to connect or
diff --git a/spec/rend-spec-v3/hsdesc-encrypt.md b/spec/rend-spec-v3/hsdesc-encrypt.md
index 834aceb..10a7d77 100644
--- a/spec/rend-spec-v3/hsdesc-encrypt.md
+++ b/spec/rend-spec-v3/hsdesc-encrypt.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-2.5"></a>
 
-## Hidden service descriptors: encryption format \[HS-DESC-ENC\]
+## Hidden service descriptors: encryption format {#HS-DESC-ENC}
 
 Hidden service descriptors are protected by two layers of encryption.
 Clients need to decrypt both layers to connect to the hidden service.
@@ -12,7 +12,7 @@ and protects against entities that do not possess valid client credentials.
 
 <a id="rend-spec-v3.txt-2.5.1"></a>
 
-### First layer of encryption \[HS-DESC-FIRST-LAYER\]
+### First layer of encryption {#HS-DESC-FIRST-LAYER}
 
 The first layer of HS descriptor encryption is designed to protect
 descriptor confidentiality against entities who don't know the public
@@ -20,7 +20,7 @@ identity key of the hidden service.
 
 <a id="rend-spec-v3.txt-2.5.1.1"></a>
 
-#### First layer encryption logic
+#### First layer encryption logic {#first-layer-logic}
 
 The encryption keys and format for the first layer of encryption are
 generated as specified in \[HS-DESC-ENCRYPTION-KEYS\] with customization
@@ -43,7 +43,7 @@ multiple of 10k bytes.
 
 <a id="rend-spec-v3.txt-2.5.1.2"></a>
 
-#### First layer plaintext format
+#### First layer plaintext format {#first-layer-plaintext}
 
 After clients decrypt the first layer of encryption, they need to parse the
 plaintext to get to the second layer ciphertext which is contained in the
@@ -138,7 +138,7 @@ Here are all the supported fields:
 
 <a id="rend-spec-v3.txt-2.5.1.3"></a>
 
-#### Client behavior \[FIRST-LAYER-CLIENT-BEHAVIOR\]
+#### Client behavior {#FIRST-LAYER-CLIENT-BEHAVIOR}
 
 ```text
     The goal of clients at this stage is to decrypt the "encrypted" field as
@@ -160,7 +160,7 @@ Here are all the supported fields:
 
 <a id="rend-spec-v3.txt-2.5.1.4"></a>
 
-#### Hiding client authorization data
+#### Hiding client authorization data {#hiding-client-auth}
 
 ```text
     Hidden services should avoid leaking whether client authorization is
@@ -183,7 +183,7 @@ Here are all the supported fields:
 
 <a id="rend-spec-v3.txt-2.5.2"></a>
 
-### Second layer of encryption \[HS-DESC-SECOND-LAYER\]
+### Second layer of encryption {#HS-DESC-SECOND-LAYER}
 
 The second layer of descriptor encryption is designed to protect descriptor
 confidentiality against unauthorized clients. If client authorization is
@@ -196,7 +196,7 @@ does not offer any additional security, but is still used.
 
 <a id="rend-spec-v3.txt-2.5.2.1"></a>
 
-#### Second layer encryption keys
+#### Second layer encryption keys {#second-layer-keys}
 
 The encryption keys and format for the second layer of encryption are
 generated as specified in \[HS-DESC-ENCRYPTION-KEYS\] with customization
@@ -213,7 +213,7 @@ parameters as follows:
 
 <a id="rend-spec-v3.txt-2.5.2.2"></a>
 
-#### Second layer plaintext format
+#### Second layer plaintext format {#second-layer-plaintext}
 
 After decrypting the second layer ciphertext, clients can finally learn the
 list of intro points etc. The plaintext has the following format:
@@ -396,7 +396,7 @@ newline.
 
 <a id="rend-spec-v3.txt-2.5.3"></a>
 
-### Deriving hidden service descriptor encryption keys \[HS-DESC-ENCRYPTION-KEYS\]
+### Deriving hidden service descriptor encryption keys {#HS-DESC-ENCRYPTION-KEYS}
 
 In this section we present the generic encryption format for hidden service
 descriptors. We use the same encryption format in both encryption layers,
@@ -439,7 +439,7 @@ Here is the key generation logic:
 
 <a id="rend-spec-v3.txt-2.5.4"></a>
 
-### Number of introduction points \[NUM_INTRO_POINT\]
+### Number of introduction points {#NUM_INTRO_POINT}
 
 This section defines how many introduction points an hidden service
 descriptor can have at minimum, by default and the maximum:
diff --git a/spec/rend-spec-v3/introduction-protocol.md b/spec/rend-spec-v3/introduction-protocol.md
index f4e6358..ebf51b2 100644
--- a/spec/rend-spec-v3/introduction-protocol.md
+++ b/spec/rend-spec-v3/introduction-protocol.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-3"></a>
 
-# The introduction protocol \[INTRO-PROTOCOL\]
+# The introduction protocol {#INTRO-PROTOCOL}
 
 The introduction protocol proceeds in three steps.
 
@@ -30,11 +30,11 @@ the introduction request to the client.
 
 <a id="rend-spec-v3.txt-3.1"></a>
 
-## Registering an introduction point \[REG_INTRO_POINT\]
+## Registering an introduction point {#REG_INTRO_POINT}
 
 <a id="rend-spec-v3.txt-3.1.1"></a>
 
-### Extensible ESTABLISH_INTRO protocol. \[EST_INTRO\]
+### Extensible ESTABLISH_INTRO protocol. {#EST_INTRO}
 
 When a hidden service is establishing a new introduction point, it
 sends an ESTABLISH_INTRO cell with the following contents:
@@ -115,7 +115,7 @@ later in INTRODUCE1 cells.
 
 <a id="rend-spec-v3.txt-3.1.1.1"></a>
 
-#### Denial-of-Service Defense Extension. \[EST_INTRO_DOS_EXT\]
+#### Denial-of-Service Defense Extension. {#EST_INTRO_DOS_EXT}
 
 This extension can be used to send Denial-of-Service (DoS) parameters to
 the introduction point in order for it to apply them for the introduction
@@ -215,7 +215,7 @@ authentication keys.
 
 <a id="rend-spec-v3.txt-3.1.3"></a>
 
-### Acknowledging establishment of introduction point \[INTRO_ESTABLISHED\]
+### Acknowledging establishment of introduction point {#INTRO_ESTABLISHED}
 
 After setting up an introduction circuit, the introduction point reports its
 status back to the hidden service host with an INTRO_ESTABLISHED cell.
@@ -240,7 +240,7 @@ apply to the extension fields here as described \[EST_INTRO\] above.
 
 <a id="rend-spec-v3.txt-3.2"></a>
 
-## Sending an INTRODUCE1 cell to the introduction point. \[SEND_INTRO1\]
+## Sending an INTRODUCE1 cell to the introduction point. {#SEND_INTRO1}
 
 In order to participate in the introduction protocol, a client must
 know the following:
@@ -267,7 +267,7 @@ or that its request will not succeed.
 
 <a id="rend-spec-v3.txt-3.2.1"></a>
 
-### INTRODUCE1 cell format \[FMT_INTRO1\]
+### INTRODUCE1 cell format {#FMT_INTRO1}
 
 When a client is connecting to an introduction point, INTRODUCE1 cells
 should be of the form:
@@ -310,7 +310,7 @@ apply to the extension fields here as described \[EST_INTRO\] above.
 
 <a id="rend-spec-v3.txt-3.2.2"></a>
 
-### INTRODUCE_ACK cell format. \[INTRO_ACK\]
+### INTRODUCE_ACK cell format. {#INTRO_ACK}
 
 An INTRODUCE_ACK cell has the following fields:
 
@@ -335,7 +335,7 @@ apply to the extension fields here as described \[EST_INTRO\] above.
 
 <a id="rend-spec-v3.txt-3.3"></a>
 
-## Processing an INTRODUCE2 cell at the hidden service. \[PROCESS_INTRO2\]
+## Processing an INTRODUCE2 cell at the hidden service. {#PROCESS_INTRO2}
 
 Upon receiving an INTRODUCE2 cell, the hidden service host checks whether
 the AUTH_KEY or LEGACY_KEY_ID field matches the keys for this
@@ -432,7 +432,7 @@ apply to the extension fields here as described \[EST_INTRO\] above.
 
 <a id="rend-spec-v3.txt-3.3.1"></a>
 
-### Introduction handshake encryption requirements \[INTRO-HANDSHAKE-REQS\]
+### Introduction handshake encryption requirements {#INTRO-HANDSHAKE-REQS}
 
 When decoding the encrypted information in an INTRODUCE2 cell, a
 hidden service host must be able to:
@@ -580,7 +580,7 @@ AES-128 and SHA1 for this hop, we use AES-256 and SHA3-256.
 
 <a id="rend-spec-v3.txt-3.4"></a>
 
-## Authentication during the introduction phase. \[INTRO-AUTH\]
+## Authentication during the introduction phase. {#INTRO-AUTH}
 
 Hidden services may restrict access only to authorized users.
 One mechanism to do so is the credential mechanism, where only users who
@@ -590,7 +590,7 @@ There is one defined authentication type: `ed25519`.
 
 <a id="rend-spec-v3.txt-3.4.1"></a>
 
-### Ed25519-based authentication `ed25519`
+### Ed25519-based authentication `ed25519` {#ed25519-auth}
 
 (NOTE: This section is not implemented by Tor.  It is likely
 that we would want to change its design substantially before
diff --git a/spec/rend-spec-v3/keyblinding-scheme.md b/spec/rend-spec-v3/keyblinding-scheme.md
index 8a7b1a2..b69a578 100644
--- a/spec/rend-spec-v3/keyblinding-scheme.md
+++ b/spec/rend-spec-v3/keyblinding-scheme.md
@@ -1,10 +1,10 @@
 <a id="rend-spec-v3.txt-A"></a>
 
-# Appendix A: Signature scheme with key blinding \[KEYBLIND\]
+# Appendix A: Signature scheme with key blinding {#KEYBLIND}
 
 <a id="rend-spec-v3.txt-A.1"></a>
 
-## Key derivation overview
+## Key derivation overview {#overview}
 
 As described in \[IMD:DIST\] and \[SUBCRED\] above, we require a "key
 blinding" system that works (roughly) as follows:
@@ -37,7 +37,7 @@ There is a master keypair (sk, pk).
 
 <a id="rend-spec-v3.txt-A.2"></a>
 
-## Tor's key derivation scheme
+## Tor's key derivation scheme {#scheme}
 
 We propose the following scheme for key blinding, based on Ed25519.
 
diff --git a/spec/rend-spec-v3/overview.md b/spec/rend-spec-v3/overview.md
index cf16ff4..61aa55a 100644
--- a/spec/rend-spec-v3/overview.md
+++ b/spec/rend-spec-v3/overview.md
@@ -34,7 +34,7 @@ Operator -- A person running a hidden service
 
 <a id="rend-spec-v3.txt-0.1"></a>
 
-## Improvements over previous versions
+## Improvements over previous versions {#improvements}
 
 Here is a list of improvements of this proposal over the legacy hidden
 services:
@@ -49,7 +49,7 @@ g) Advanced client authorization
 
 <a id="rend-spec-v3.txt-0.2"></a>
 
-## Notation and vocabulary
+## Notation and vocabulary {#notation}
 
 Unless specified otherwise, all multi-octet integers are big-endian.
 
@@ -76,7 +76,7 @@ INT_4(42) is 42 % 4294967296 (32 bit).
 
 <a id="rend-spec-v3.txt-0.3"></a>
 
-## Cryptographic building blocks
+## Cryptographic building blocks {#cryptography}
 
 This specification uses the following cryptographic building blocks:
 
@@ -147,7 +147,7 @@ value.
 
 <a id="rend-spec-v3.txt-0.4"></a>
 
-## Protocol building blocks \[BUILDING-BLOCKS\]
+## Protocol building blocks {#BUILDING-BLOCKS}
 
 In sections below, we need to transmit the locations and identities
 of Tor nodes. We do so in the link identification format used by
@@ -183,7 +183,7 @@ server's public key.
 
 <a id="rend-spec-v3.txt-0.5"></a>
 
-## Assigned relay cell types
+## Assigned relay cell types {#relay-cell-types}
 
 These relay cell types are reserved for use in the hidden service
 protocol.
diff --git a/spec/rend-spec-v3/protocol-overview.md b/spec/rend-spec-v3/protocol-overview.md
index 173240e..afc2dd1 100644
--- a/spec/rend-spec-v3/protocol-overview.md
+++ b/spec/rend-spec-v3/protocol-overview.md
@@ -8,7 +8,7 @@ fully below, when we specify the protocol in more detail.
 
 <a id="rend-spec-v3.txt-1.1"></a>
 
-## View from 10,000 feet
+## View from 10,000 feet {#10000-feet}
 
 A hidden service host prepares to offer a hidden service by choosing
 several Tor nodes to serve as its introduction points. It builds
@@ -47,7 +47,7 @@ communicate data on those streams, and so forth.
 
 <a id="rend-spec-v3.txt-1.2"></a>
 
-## In more detail: naming hidden services \[NAMING\]
+## In more detail: naming hidden services {#NAMING}
 
 A hidden service's name is its long term master identity key.  This is
 encoded as a hostname by encoding the entire key in Base 32, including a
@@ -73,7 +73,7 @@ their length. An older name might look like:
 
 <a id="rend-spec-v3.txt-1.3"></a>
 
-## In more detail: Access control \[IMD:AC\]
+## In more detail: Access control {#IMD:AC}
 
 Access control for a hidden service is imposed at multiple points through
 the process above. Furthermore, there is also the option to impose
@@ -108,7 +108,7 @@ require the client to prove knowledge of a pre-shared private key.
 
 <a id="rend-spec-v3.txt-1.4"></a>
 
-## In more detail: Distributing hidden service descriptors. \[IMD:DIST\]
+## In more detail: Distributing hidden service descriptors. {#IMD:DIST}
 
 Periodically, hidden service descriptors become stored at different
 locations to prevent a single directory or small set of directories
@@ -153,7 +153,7 @@ until the new keys come online.
 
 <a id="rend-spec-v3.txt-1.5"></a>
 
-## In more detail: Scaling to multiple hosts
+## In more detail: Scaling to multiple hosts {#imd-scaling}
 
 This design is compatible with our current approaches for scaling hidden
 services. Specifically, hidden service operators can use onionbalance to
@@ -175,7 +175,7 @@ introduction points.
 
 <a id="rend-spec-v3.txt-1.7"></a>
 
-## In more detail: Keeping crypto keys offline
+## In more detail: Keeping crypto keys offline {#imd-offline-keys}
 
 In this design, a hidden service's secret identity key may be
 stored offline.  It's used only to generate blinded signing keys,
@@ -202,7 +202,7 @@ implemented as of 0.3.2.1-alpha.)
 
 <a id="rend-spec-v3.txt-1.8"></a>
 
-## In more detail: Encryption Keys And Replay Resistance
+## In more detail: Encryption Keys And Replay Resistance {#imd-encryption-keys}
 
 To avoid replays of an introduction request by an introduction point,
 a hidden service host must never accept the same request
@@ -213,7 +213,7 @@ discussion.)
 
 <a id="rend-spec-v3.txt-1.9"></a>
 
-## In more detail: A menagerie of keys
+## In more detail: A menagerie of keys {#imd-key-menagerie}
 
 \[In the text below, an "encryption keypair" is roughly "a keypair you
 can do Diffie-Hellman with" and a "signing keypair" is roughly "a
@@ -292,7 +292,7 @@ Public/private keypairs defined in this document:
 
 <a id="rend-spec-v3.txt-1.9.1"></a>
 
-### In even more detail: Client authorization keys \[CLIENT-AUTH\]
+### In even more detail: Client authorization keys {#CLIENT-AUTH}
 
 When client authorization is enabled, each authorized client of a hidden
 service has two more asymmetric keypairs which are shared with the hidden
diff --git a/spec/rend-spec-v3/rendezvous-protocol.md b/spec/rend-spec-v3/rendezvous-protocol.md
index 683d9e4..d102111 100644
--- a/spec/rend-spec-v3/rendezvous-protocol.md
+++ b/spec/rend-spec-v3/rendezvous-protocol.md
@@ -21,7 +21,7 @@ but use an anonymous 3-hop circuit if:
 
 <a id="rend-spec-v3.txt-4.1"></a>
 
-## Establishing a rendezvous point \[EST_REND_POINT\]
+## Establishing a rendezvous point {#EST_REND_POINT}
 
 The client sends the rendezvous point a RELAY_COMMAND_ESTABLISH_RENDEZVOUS
 cell containing a 20-byte value.
@@ -50,7 +50,7 @@ connect to a hidden service.
 
 <a id="rend-spec-v3.txt-4.2"></a>
 
-## Joining to a rendezvous point \[JOIN_REND\]
+## Joining to a rendezvous point {#JOIN_REND}
 
 To complete a rendezvous, the hidden service host builds a circuit to
 the rendezvous point and sends a RENDEZVOUS1 cell containing:
@@ -118,7 +118,7 @@ should make it extensible.\]
 
 <a id="rend-spec-v3.txt-4.3"></a>
 
-## Using legacy hosts as rendezvous points
+## Using legacy hosts as rendezvous points {#legacy-rend-hosts}
 
 \[This section is obsolete and refers to a workaround for now-obsolete Tor
 relay versions. It is included for historical reasons.\]
diff --git a/spec/rend-spec-v3/shared-random.md b/spec/rend-spec-v3/shared-random.md
index 707c7da..b06558f 100644
--- a/spec/rend-spec-v3/shared-random.md
+++ b/spec/rend-spec-v3/shared-random.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-2.3"></a>
 
-## Publishing shared random values \[PUB-SHAREDRANDOM\]
+## Publishing shared random values {#PUB-SHAREDRANDOM}
 
 Our design for limiting the predictability of HSDir upload locations
 relies on a shared random value (SRV) that isn't predictable in advance or
@@ -19,7 +19,7 @@ According to proposal 250, we add two new lines in consensuses:
 
 <a id="rend-spec-v3.txt-2.3.1"></a>
 
-### Client behavior in the absence of shared random values
+### Client behavior in the absence of shared random values {#client-disaster}
 
 If the previous or current shared random value cannot be found in a
 consensus, then Tor clients and services need to generate their own random
@@ -36,7 +36,7 @@ found originally.
 
 <a id="rend-spec-v3.txt-2.3.2"></a>
 
-### Hidden services and changing shared random values
+### Hidden services and changing shared random values {#service-problems}
 
 It's theoretically possible that the consensus shared random values will
 change or disappear in the middle of a time period because of directory