6 files changed, 201 insertions, 6 deletions
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 7e37484..0860c88 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -166,7 +166,7 @@ Proposals by number:
 242  Better performance and usability for the MyFamily option [SUPERSEDED]
 243  Give out HSDir flag only to relays with Stable flag [CLOSED]
 244  Use RFC5705 Key Exporting in our AUTHENTICATE calls [CLOSED]
-245  Deprecating and removing the TAP circuit extension protocol [NEEDS-REVISION]
+245  Deprecating and removing the TAP circuit extension protocol [SUPERSEDED]
 246  Merging Hidden Service Directories and Introduction Points [REJECTED]
 247  Defending Against Guard Discovery Attacks using Vanguards [SUPERSEDED]
 248  Remove all RSA identity keys [NEEDS-REVISION]
@@ -271,6 +271,7 @@ Proposals by number:
 347  Domain separation for certificate signing keys [OPEN]
 348  UDP Application Support in Tor [OPEN]
 349  Client-Side Command Acceptance Validation [DRAFT]
+350  A phased plan to remove TAP onion keys [OPEN]
 
 
 Proposals by status:
@@ -284,7 +285,6 @@ Proposals by status:
  NEEDS-REVISION:
    212  Increase Acceptable Consensus Age [for 0.2.4.x+]
    219  Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x]
-   245  Deprecating and removing the TAP circuit extension protocol
    248  Remove all RSA identity keys
    269  Transitionally secure hybrid handshakes
    279  A Name System API for Tor Onion Services
@@ -311,6 +311,7 @@ Proposals by status:
    346  Clarifying and extending the use of protocol versioning
    347  Domain separation for certificate signing keys
    348  UDP Application Support in Tor
+   350  A phased plan to remove TAP onion keys
  ACCEPTED:
    282  Remove "Named" and "Unnamed" handling from consensus voting [for arti-dirauth]
    285  Directory documents should be standardized as UTF-8 [for arti-dirauth]
@@ -462,6 +463,7 @@ Proposals by status:
    210  Faster Headless Consensus Bootstrapping
    225  Strawman proposal: commit-and-reveal shared rng
    242  Better performance and usability for the MyFamily option
+   245  Deprecating and removing the TAP circuit extension protocol
    247  Defending Against Guard Discovery Attacks using Vanguards
    249  Allow CREATE cells with >505 bytes of handshake data
    252  Single Onion Services
diff --git a/proposals/245-tap-out.txt b/proposals/245-tap-out.txt
index 6edc3f9..ec5a7ff 100644
--- a/proposals/245-tap-out.txt
+++ b/proposals/245-tap-out.txt
@@ -3,7 +3,8 @@ Filename: 245-tap-out.txt
 Title: Deprecating and removing the TAP circuit extension protocol
 Author: Nick Mathewson
 Created: 2015-06-02
-Status: Needs-Revision
+Status: Superseded
+Superseded-by: 350
 
 0. Introduction
 
diff --git a/proposals/350-remove-tap.md b/proposals/350-remove-tap.md
new file mode 100644
index 0000000..7fa83bd
--- /dev/null
+++ b/proposals/350-remove-tap.md
@@ -0,0 +1,189 @@
+```
+Filename: 350-remove-tap.md
+Title: A phased plan to remove TAP onion keys
+Author: Nick Mathewson
+Created: 31 May 2024
+Status: Open
+```
+
+## Introduction
+
+Back in [proposal 216], we introduced the `ntor` circuit extension handshake.
+It replaced the older `TAP` handshake, which was badly designed,
+and dependent on insecure key lengths (RSA1024, DH1024).
+
+With the [final shutdown of v2 onion services][hsv2-deprecation],
+there are no longer any supported users of TAP anywhere in the Tor protocols.
+Anecdotally, a relay operator reports that fewer than
+one handshake in 300,000 is currently TAP.
+(Such handshakes are presumably coming from long-obsolete clients.)
+
+Nonetheless, we continue to bear burdens from TAP support.
+For example:
+  - TAP keys compose a significant (but useless!) portion
+    of directory traffic.
+  - The TAP handshake requires cryptographic primitives
+    used nowhere else in the Tor protocols.
+
+Now that we are implementing [relays in Arti],
+the time is ripe to remove TAP.
+(The only alternative is to add a useless TAP implementation in Arti,
+which would be a waste of time.)
+
+This document outlines a plan to completely remove the TAP handshake,
+and its associated keys, from the Tor protocols.
+
+This is, in some respects, a modernized version of [proposal 245].
+
+## Migration plan
+
+Here is the plan in summary;
+we'll discuss each phase below.
+
+- Phase 1: Remove TAP dependencies
+  - Item 1: Stop accepting TAP circuit requests.
+  - Item 2: Make TAP keys optional in directory documents.
+  - Item 3: Publish dummy TAP keys.
+- Phase 2: After everybody has updated
+  - Item 1: Allow TAP-free routerdescs at the authorities
+  - Item 2: Generate TAP-free microdescriptors
+- Phase 3: Stop publishing dummy TAP keys.
+
+Phase 1 can begin immediately.
+
+Phase 2 can begin once all supported clients and relays have upgraded
+to run versions with the changes made in Phase 1.
+
+Phase 3 can begin once all authorities have made the changes
+described in phase 2.
+
+
+### Phase 1, Item 1: Stop accepting TAP circuit requests.
+
+(All items in phase 1 can happen in parallel.)
+
+Immediately, Tor relays should stop accepting TAP requests.
+This includes all CREATE cells (not CREATE2),
+and any CREATE2 cell whose type is TAP (0x0000).
+
+When receiving such a request,
+relays should respond with DESTROY.
+Relays MAY just drop the request entirely, however,
+if they find that they are getting too many requests.
+
+Such relays must stop reporting `Relay=1`
+among their supported protocol versions.
+(This protocol version is not currently required or recommended.)
+
+> If this proposal is accepted,
+> we should clarify the protocol version specification
+> to say that `Relay=1` specifically denotes TAP.
+
+
+### Phase 1, Item 2: Make TAP keys optional in directory documents.
+
+(All items in phase 1 can happen in parallel.)
+
+In C tor and Arti, we should make the `onion-key` entry
+and the `onion-key-crosscert` entry optional.
+(If either is present, the other still must be present.)
+
+When we do this, we should also modify the authority code
+to reject any descriptors that do not have these fields.
+(This will be needed so that existing Tor instances do not break.)
+
+In the microdescriptor documents format, we should make
+the _object_ of the `onion-key` element optional.
+(We do not want to make the element itself optional,
+since it is used to delimit microdescriptors.)
+
+We use new protocol version flags (Desc=X, Routerdesc=Y)
+to note the ability to parse these documents.
+
+### Phase 1, Item 3: Publish dummy TAP keys
+
+(All items in phase 1 can happen in parallel.)
+
+Even after step 2 is done,
+many clients and relays on the network
+will still require TAP keys to be present in directory documents.
+Therefore, we can't remove those keys right away.
+
+Relays, therefore, must put _some_ kind of RSA key
+into their `onion-key` field.
+
+I'll present three designs on what relays should do.
+We should pick one.
+
+> #### Option 1 (conservative)
+>
+> Maybe, we should say that a relay
+> should generate a TAP key, generate an onion-key-crosscert,
+> and then discard the private component of the key.
+
+> #### Option 2 (low-effort)
+>
+> In C tor, we can have relays simply proceed as they do now,
+> maintaining TAP private keys and generating crosscerts.
+>
+> This has little real risk beyond what is described in Option 1.
+
+> #### Option 3 (nutty)
+>
+> We _could_ generate a global, shared RSA1024 private key,
+> to be used only for generating onion-key-crosscerts
+> and placing into the onion-key field of a descriptor.
+>
+> We would say that relays publishing this key MUST NOT
+> actually handle any TAP requests.
+>
+> The advantage of this approach over Option 1
+> would be that we'd see gains in our directory traffic
+> immediately, since all identical onion keys would be
+> highly compressible.
+>
+> The downside here is that any client TAP requests
+> sent to such a relay would be decryptable by anybody,
+> which would expose long-obsolete clients to MITM attacks
+> by hostile guards.
+
+We would control the presence of these dummy TAP keys
+using a consensus parameter:
+
+`publish-dummy-tap-key` —  If set to 1, relays should include a dummy TAP key
+in their routerdescs.  If set to 0, relays should omit the TAP key
+and corresponding crosscert. (Min: 0, Max, 1, Default: 0.)
+
+We would want to ensure that all authorities voted for this parameter as "1"
+before enabling support for it at the relay level.
+
+
+### Phase 2, Item 1: Allow TAP-free routerdescs at the authorities
+
+Once all clients and relays have updated to a version
+where the `onion-key` router descriptor element is optional
+(see phase 1, item 2),
+we can remove the authority code that requires
+all descriptors to have TAP keys.
+
+### Phase 2, Item 2: Generate TAP-free microdescriptors
+
+Once all clients and descriptors have updated to a version
+where the `onion-key` body is optional in microdescriptors
+(see phase 1, item 2),
+we can add a new consensus method
+in which authorities omit the body when generating microdescriptors.
+
+### Phase 3: Stop publishing dummy TAP keys.
+
+Once all authorities have stopped requiring
+the `onion-key` element in router descriptors
+(see phase 2, item 1),
+we can disable the `publish-dummy-tap-key` consensus parameter,
+so that relays will no longer include TAP keys in their router descriptors.
+
+
+[proposal 216]: ./216-ntor-handshake.txt
+[proposal 245]: ./245-tap-out.txt
+[hsv2-deprecation]: https://support.torproject.org/onionservices/v2-deprecation/
+[relays in Arti]: https://gitlab.torproject.org/tpo/team/-/wikis/Sponsor%20141
diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md
index 96e52b0..8d9380a 100644
--- a/proposals/BY_INDEX.md
+++ b/proposals/BY_INDEX.md
@@ -162,7 +162,7 @@ Below are a list of proposals sorted by their proposal number.  See
 * [`242-better-families.txt`](/proposals/242-better-families.txt): Better performance and usability for the MyFamily option \[SUPERSEDED\]
 * [`243-hsdir-flag-need-stable.txt`](/proposals/243-hsdir-flag-need-stable.txt): Give out HSDir flag only to relays with Stable flag \[CLOSED\]
 * [`244-use-rfc5705-for-tls-binding.txt`](/proposals/244-use-rfc5705-for-tls-binding.txt): Use RFC5705 Key Exporting in our AUTHENTICATE calls \[CLOSED\]
-* [`245-tap-out.txt`](/proposals/245-tap-out.txt): Deprecating and removing the TAP circuit extension protocol \[NEEDS-REVISION\]
+* [`245-tap-out.txt`](/proposals/245-tap-out.txt): Deprecating and removing the TAP circuit extension protocol \[SUPERSEDED\]
 * [`246-merge-hsdir-and-intro.txt`](/proposals/246-merge-hsdir-and-intro.txt): Merging Hidden Service Directories and Introduction Points \[REJECTED\]
 * [`247-hs-guard-discovery.txt`](/proposals/247-hs-guard-discovery.txt): Defending Against Guard Discovery Attacks using Vanguards \[SUPERSEDED\]
 * [`248-removing-rsa-identities.txt`](/proposals/248-removing-rsa-identities.txt): Remove all RSA identity keys \[NEEDS-REVISION\]
@@ -267,4 +267,5 @@ Below are a list of proposals sorted by their proposal number.  See
 * [`347-domain-separation.md`](/proposals/347-domain-separation.md): Domain separation for certificate signing keys \[OPEN\]
 * [`348-udp-app-support.md`](/proposals/348-udp-app-support.md): UDP Application Support in Tor \[OPEN\]
 * [`349-command-state-validation.md`](/proposals/349-command-state-validation.md): Client-Side Command Acceptance Validation \[DRAFT\]
+* [`350-remove-tap.md`](/proposals/350-remove-tap.md): A phased plan to remove TAP onion keys \[OPEN\]
 
diff --git a/proposals/BY_STATUS.md b/proposals/BY_STATUS.md
index 84345ac..2455afe 100644
--- a/proposals/BY_STATUS.md
+++ b/proposals/BY_STATUS.md
@@ -41,6 +41,7 @@ for discussion.
 * [`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
+* [`350-remove-tap.md`](/proposals/350-remove-tap.md): A phased plan to remove TAP onion keys
 
 
 ## ACCEPTED proposals: slated for implementation
@@ -113,7 +114,6 @@ certain changes.
 
 * [`212-using-old-consensus.txt`](/proposals/212-using-old-consensus.txt): Increase Acceptable Consensus Age
 * [`219-expanded-dns.txt`](/proposals/219-expanded-dns.txt): Support for full DNS and DNSSEC resolution in Tor
-* [`245-tap-out.txt`](/proposals/245-tap-out.txt): Deprecating and removing the TAP circuit extension protocol
 * [`248-removing-rsa-identities.txt`](/proposals/248-removing-rsa-identities.txt): Remove all RSA identity keys
 * [`269-hybrid-handshake.txt`](/proposals/269-hybrid-handshake.txt): Transitionally secure hybrid handshakes
 * [`279-naming-layer-api.txt`](/proposals/279-naming-layer-api.txt): A Name System API for Tor Onion Services
@@ -297,6 +297,7 @@ implemented.
 * [`210-faster-headless-consensus-bootstrap.txt`](/proposals/210-faster-headless-consensus-bootstrap.txt): Faster Headless Consensus Bootstrapping
 * [`225-strawman-shared-rand.txt`](/proposals/225-strawman-shared-rand.txt): Strawman proposal: commit-and-reveal shared rng
 * [`242-better-families.txt`](/proposals/242-better-families.txt): Better performance and usability for the MyFamily option
+* [`245-tap-out.txt`](/proposals/245-tap-out.txt): Deprecating and removing the TAP circuit extension protocol
 * [`247-hs-guard-discovery.txt`](/proposals/247-hs-guard-discovery.txt): Defending Against Guard Discovery Attacks using Vanguards
 * [`249-large-create-cells.txt`](/proposals/249-large-create-cells.txt): Allow CREATE cells with >505 bytes of handshake data
 * [`252-single-onion.txt`](/proposals/252-single-onion.txt): Single Onion Services
diff --git a/proposals/SUMMARY.md b/proposals/SUMMARY.md
index 09e1270..477002b 100644
--- a/proposals/SUMMARY.md
+++ b/proposals/SUMMARY.md
@@ -155,7 +155,7 @@
  - [`242-better-families`](./242-better-families.txt): Better performance and usability for the MyFamily option (SUPERSEDED)
  - [`243-hsdir-flag-need-stable`](./243-hsdir-flag-need-stable.txt): Give out HSDir flag only to relays with Stable flag (CLOSED)
  - [`244-use-rfc5705-for-tls-binding`](./244-use-rfc5705-for-tls-binding.txt): Use RFC5705 Key Exporting in our AUTHENTICATE calls (CLOSED)
- - [`245-tap-out`](./245-tap-out.txt): Deprecating and removing the TAP circuit extension protocol (NEEDS-REVISION)
+ - [`245-tap-out`](./245-tap-out.txt): Deprecating and removing the TAP circuit extension protocol (SUPERSEDED)
  - [`246-merge-hsdir-and-intro`](./246-merge-hsdir-and-intro.txt): Merging Hidden Service Directories and Introduction Points (REJECTED)
  - [`247-hs-guard-discovery`](./247-hs-guard-discovery.txt): Defending Against Guard Discovery Attacks using Vanguards (SUPERSEDED)
  - [`248-removing-rsa-identities`](./248-removing-rsa-identities.txt): Remove all RSA identity keys (NEEDS-REVISION)
@@ -260,6 +260,7 @@
  - [`347-domain-separation`](./347-domain-separation.md): Domain separation for certificate signing keys (OPEN)
  - [`348-udp-app-support`](./348-udp-app-support.md): UDP Application Support in Tor (OPEN)
  - [`349-command-state-validation`](./349-command-state-validation.md): Client-Side Command Acceptance Validation (DRAFT)
+ - [`350-remove-tap`](./350-remove-tap.md): A phased plan to remove TAP onion keys (OPEN)