14 files changed, 260 insertions, 13 deletions
diff --git a/mdbook/proposals/book.toml b/mdbook/proposals/book.toml
index 5253388..a5d85fb 100644
--- a/mdbook/proposals/book.toml
+++ b/mdbook/proposals/book.toml
@@ -288,4 +288,6 @@ enable = false
 "/346.html" = "./346-protovers-again.html"
 "/347.html" = "./347-domain-separation.html"
 "/348.html" = "./348-udp-app-support.html"
+"/349.html" = "./349-command-state-validation.html"
+"/350.html" = "./350-remove-tap.html"
 # END AUTO-GENERATED REDIRECTS
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/339-udp-over-tor.md b/proposals/339-udp-over-tor.md
index 12de0c6..e5235d1 100644
--- a/proposals/339-udp-over-tor.md
+++ b/proposals/339-udp-over-tor.md
@@ -11,7 +11,7 @@ Status: Accepted
 Tor currently only supports delivering two kinds of traffic to the
 internet: TCP data streams, and a certain limited subset of DNS
 requests. This proposal describes a plan to extend the Tor protocol so
-that exit relays can also relay UDP traffic to the network?.
+that exit relays can also relay UDP traffic to the network.
 
 Why would we want to do this?  There are important protocols that use
 UDP, and in order to support users that rely on these protocols, we'll
diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md
index 2407f99..cd98cfd 100644
--- a/proposals/340-packed-and-fragmented.md
+++ b/proposals/340-packed-and-fragmented.md
@@ -269,8 +269,23 @@ conflux bundle.
 
 ### An exception for `DATA`.
 
-Data messages may not be fragmented.  (There is never a reason to do
-this.)
+Data messages may not be fragmented. When packing data into a cell containing
+other messages is desired, the application can instead construct a DATA message
+of an appropriate size to fit into the remaining space.
+
+While relaxing this could simplify the implementation of opportunistic packing
+somewhat (by allowing code that constructs `DATA` messages not to have to know
+about packing or fragmentation), doing so would have several downsides.
+
+First, on the receiver side a naive implementation that receives the first cell
+of a fragmented `DATA` message would not be able to pass the data in that
+fragment on to the application until the remaining cells of that message are
+received. An optimized implementation might choose to do so, but that
+complexity seems worse than the complexity we'd be avoiding by allowing `DATA`
+fragmentation in the first place.
+
+Second, as with any sort of flexibility permitted to implementations, allowing
+flexibility here adds opportunities for fingerprinting and covert channels.
 
 ### Extending message-length maxima
 
@@ -286,6 +301,32 @@ Any increase in maximum length for any other message type requires a new
 EXTEND2 messages to be 2000 bytes long, we need to add a new proposal
 saying so, and reserving a new subprotocol version.)
 
+### `SENDME` window accounting
+
+`SENDME` windows count relay *cells* rather than relay *messages*.
+
+A cell counts towards the circuit's `SENDME` window if it contains any part of
+any message that would normally count towards `SENDME` windows (currently only
+`DATA`).
+
+A cell counts towards the `SENDME` window of every stream that it contains
+part of a message for, whose command counts towards `SENDME` windows.
+
+Examples:
+
+* A cell containing a `SENDME` message and a `RESOLVE` message currently
+  wouldn't count towards any windows, since neither of those commands currently
+  counts towards windows.
+* A cell containing a `SENDME` message and a `DATA` message would count towards
+  the circuit window and the `DATA` message's stream's window.
+* A cell containing two `DATA` messages, for different streams, would count
+  towards the circuit-level window and both stream-level windows.
+* A cell containing two `DATA` messages for the *same* stream counts
+  *once* towards the circuit-level and stream-level windows.
+* If `DATAGRAM` messages (proposal 339) are implemented, and count towards
+  windows, then every cell containing a fragment of a `DATAGRAM` message counts
+  towards windows.
+
 # Appendix: Example cells
 
 Here is an example of the simplest case: one message, sent in one relay cell:
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)
 
 
 
diff --git a/spec/SUMMARY.md b/spec/SUMMARY.md
index ade9586..70fa46a 100644
--- a/spec/SUMMARY.md
+++ b/spec/SUMMARY.md
@@ -127,7 +127,7 @@
   - [Appendix F: Hidden service directory format \[HIDSERVDIR-FORMAT\]](./rend-spec/fs-contents.md)
   - [Appendix G: Managing authorized client data \[CLIENT-AUTH-MGMT\]](./rend-spec/client-authorization.md)
   - [Appendix F: Two methods for managing revision counters.](./rend-spec/revision-counter-mgt.md)
-  - [Appendix G: Text vectors](./rend-spec/text-vectors.md)
+  - [Appendix G: Test vectors](./rend-spec/test-vectors.md)
 - [`Proof of Work for onion service introduction`](./hspow-spec/index.md)
   - [Motivation](./hspow-spec/motivation.md)
   - [Common protocol](./hspow-spec/common-protocol.md)
diff --git a/spec/cert-spec.md b/spec/cert-spec.md
index 873c258..98aeffa 100644
--- a/spec/cert-spec.md
+++ b/spec/cert-spec.md
@@ -57,7 +57,7 @@ These representation for this certificate is:
 | - `ExtType`      | 1    | [Type of extension](#list-ext-types)|
 | - `ExtFlags`     | 1    | Control interpretation of extension |
 | - `ExtData`      | `ExtLen` | Encoded extension body          |
-| SIGNATURE        | 64   | Signature of all previous fields    |
+| `SIGNATURE`      | 64   | Signature of all previous fields    |
 
 
 The `VERSION` field holds the value `[01]`.
diff --git a/spec/rend-spec/encrypting-user-data.md b/spec/rend-spec/encrypting-user-data.md
index 460f71e..fdf1a30 100644
--- a/spec/rend-spec/encrypting-user-data.md
+++ b/spec/rend-spec/encrypting-user-data.md
@@ -10,3 +10,10 @@ Tor relay encryption protocol, applying encryption with these keys
 before other encryption, and decrypting with these keys before other
 decryption. The client encrypts with Kf and decrypts with Kb; the
 service host does the opposite.
+
+As mentioned
+[previously](./introduction-protocol.md#INTRO-HANDSHAKE-REQS),
+these keys are used the same as for
+[regular relay cell encryption](../tor-spec/routing-relay-cells.md),
+except that instead of using AES-128 and SHA1,
+both parties use AES-256 and SHA3-256.
diff --git a/spec/rend-spec/introduction-protocol.md b/spec/rend-spec/introduction-protocol.md
index 43c5638..0181dd2 100644
--- a/spec/rend-spec/introduction-protocol.md
+++ b/spec/rend-spec/introduction-protocol.md
@@ -696,7 +696,9 @@ HANDSHAKE_INFO element (see \[JOIN_REND\]).
 The hidden service host now also knows the keys generated by the
 handshake, which it will use to encrypt and authenticate data
 end-to-end between the client and the server. These keys are as
-computed in tor-spec.txt section 5.1.4, except that instead of using
+computed with the
+[ntor handshake](../tor-spec/create-created-cells.html#ntor),
+except that instead of using
 AES-128 and SHA1 for this hop, we use AES-256 and SHA3-256.
 
 <a id="rend-spec-v3.txt-3.4"></a>
diff --git a/spec/rend-spec/text-vectors.md b/spec/rend-spec/test-vectors.md
index eadaee2..d77049e 100644
--- a/spec/rend-spec/text-vectors.md
+++ b/spec/rend-spec/test-vectors.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-G"></a>
 
-# Appendix G: Text vectors
+# Appendix G: Test vectors
 
 G.1. Test vectors for hs-ntor / NTOR-WITH-EXTRA-DATA