Merge remote-tracking branches 'tor-gitlab/mr/114' and 'tor-gitlab/mr/115'

3 files changed, 62 insertions, 27 deletions

diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md
index e7f08f4..6fb1ca5 100644
--- a/proposals/340-packed-and-fragmented.md
+++ b/proposals/340-packed-and-fragmented.md
@@ -33,6 +33,9 @@ This proposal combines ideas from
 [ntor v3](./332-ntor-v3-with-extra-data.md) and prepares for
 [next-generation relay cryptography](./308-counter-galois-onion).
 
+Additionally, this proposal has been revised to incorporate another
+protocol change, and remove StreamId from the relay cell header.
+
 ## A preliminary change: Relay encryption, version 1.5
 
 We are fairly sure that, whatever we do for our next batch of relay
@@ -66,12 +69,15 @@ Relay _messages_ now follow the following format:
   Header
     command   u8
     length    u16
-    stream_id u16
   Body
     data      u8[length]
 
 We require that "command" is never 0.
 
+One big change from the current tor protocol is something that is _not_
+here: we have moved `stream_id` into the body of the relay message of
+those commands that need it.
+
 Messages can be split across relay cells; multiple messages can occur in
 a single relay cell.  We enforce the following rules:
 
@@ -92,7 +98,7 @@ Receivers MUST validate that headers are well-formed and have valid
 lengths while handling the cell in which the header is encoded.  If the
 header is invalid, the receiver must destroy the circuit.
 
-### Some examples
+
 
 
 ## Negotiation
@@ -109,6 +115,42 @@ The `version` field is the `Relay` subprotocol version that the client
 wants to use. The relay must send back the same extension in its ntor3
 handshake to acknowledge support.
 
+
+## Specifying the message format with moved stream ID.
+
+Here, we'll specify how to adjust tor-spec to describe the `stream_id`
+move correctly.
+
+Below, suppose that `Relay=V` denotes whatever version of the relay
+message subprotocol denotes support for this proposal.
+
+For all relay message types that include a stream ID, we insert
+the following at the beginning of their fields:
+
+>```
+>        STREAM_ID [2 bytes] (Present when Relay protocol version >= V).
+>```
+
+We add a note saying:
+
+> STREAM_ID is part of many message types, when using Relay protocol
+> version V or later.  Earlier versions of the Relay protocol put
+> STREAM_ID in the RELAY header.  In those versions, the field is
+> STREAM_ID omitted from the message.
+>
+> Except when noted, STREAM_ID may not be zero.
+
+The following message types take required stream IDs: `BEGIN`, `DATA`, `END`,
+`CONNECTED`, `RESOLVE`, `RESOLVED`, and `BEGIN_DIR`, `XON`, `XOFF`.
+
+The following message type takes an *optional* stream ID: `SENDME`.
+(*Stream-level sendmes are not a thing anymore with proposal 324, but I
+want to give implementations the freedom to implement prop324 and this
+proposal in either order.*)
+
+The following message types from proposal 339 (UDP) take required stream
+IDs: `CONNECT_UDP`, `CONNECTED_UDP` and `DATAGRAM`.
+
 ## Migration
 
 We add a consensus parameter, "streamed-relay-messages", with default
@@ -191,8 +233,8 @@ cell.  Here it is a BEGIN message.
     message header:
        command        BEGIN             [1 byte]
        length         23                [2 bytes]
-       stream_id      (...)             [2 bytes]
     message body
+       stream_id      (...)             [2 bytes]
       "www.torproject.org:443\0"        [23 bytes]
     end-of-messages marker
       0                                 [1 byte]
@@ -215,8 +257,8 @@ across two relay cells.
     message header:
        command        EXTEND            [1 byte]
        length         800               [2 bytes]
-       stream_id      0                 [2 bytes]
     message body
+       stream_id      0                 [2 bytes]
        (extend body, part 1)            [488 bytes]
 
   Cell 2:
@@ -249,14 +291,13 @@ message in the same cell.
     message header:
        command        BEGIN_DIR         [1 byte]
        length         0                 [2 bytes]
-       stream_id      32                [2 bytes]
     message body:
-       (empty)        ---               [0 bytes]
+       stream_id      32                [2 bytes]
     message header:
        command        DATA              [1 byte]
        length         25                [2 bytes]
-       stream_id      32                [2 bytes]
     message body:
+       stream_id      32                [2 bytes]
        "HTTP/1.0 GET /tor/foo\r\n\r\n"  [25 bytes]
     end-of-messages marker
       0                                 [1 byte]
@@ -281,8 +322,8 @@ above; this is only an example of what parties need to accept.)
     message header:
        command        DATAGRAM         [1 byte]
        length         1200             [2 bytes]
-       stream_id      99               [2 bytes]
     message body
+       stream_id      99               [2 bytes]
        (datagram body, part 1)         [488 bytes]
 
   Cell 2:
@@ -307,16 +348,16 @@ above; this is only an example of what parties need to accept.)
     message header:
        command        SENDME           [1 byte]
        length         23               [2 bytes]
-       stream_id      0                [2 bytes]
     message body:
+       stream_id      0                [2 bytes]
        version        1                [1 byte]
        datalen        20               [2 bytes]
        data           (digest to ack)  [20 bytes]
     message header:
        command        XON              [1 byte]
        length         1                [2 bytes]
-       stream_id      50               [2 bytes]
     message body:
+       stream_id      50               [2 bytes]
        version        1                [1 byte]
     end-of-messages marker
       0                                [1 byte]
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt
index c1d9a2a..0dc20db 100644
--- a/rend-spec-v3.txt
+++ b/rend-spec-v3.txt
@@ -817,7 +817,7 @@ Table of contents:
    derived, the uploading or downloading party calculates:
 
         for replicanum in 1...hsdir_n_replicas:
-            hs_index(replicanum) = H("store-at-idx" |
+            hs_service_index(replicanum) = H("store-at-idx" |
                                      blinded_public_key |
                                      INT_8(replicanum) |
                                      INT_8(period_length) |
@@ -831,7 +831,7 @@ Table of contents:
    Then, for each node listed in the current consensus with the HSDir flag,
    we compute a directory index for that node as:
 
-           hsdir_index(node) = H("node-idx" | node_identity |
+           hs_relay_index(node) = H("node-idx" | node_identity |
                                  shared_random_value |
                                  INT_8(period_num) |
                                  INT_8(period_length) )
@@ -842,7 +842,7 @@ Table of contents:
 
    Finally, for replicanum in 1...hsdir_n_replicas, the hidden service
    host uploads descriptors to the first hsdir_spread_store nodes whose
-   indices immediately follow hs_index(replicanum). If any of those
+   indices immediately follow hs_service_index(replicanum). If any of those
    nodes have already been selected for a lower-numbered replica of the
    service, any nodes already chosen are disregarded (i.e. skipped over)
    when choosing a replica's hsdir_spread_store nodes.
@@ -1215,7 +1215,7 @@ Table of contents:
 
       If client authorization is disabled, the value here should be "x25519".
 
-     "desc-auth-ephemeral-key" SP key NL
+     "desc-auth-ephemeral-key" SP KP_hs_desc_ephem NL
 
       [Exactly once]
 
@@ -1242,21 +1242,15 @@ Table of contents:
       a pre-shared x25519 keypair (`KP_hsc_desc_enc`) which is used to
       decrypt the descriptor cookie.
 
+
       We now describe the descriptor cookie encryption scheme. Here are the
       relevant keys:
 
-          # KS/KP_hsc_desc_enc
-          client_x = private x25519 key of authorized client
-          client_X = public x25519 key of authorized client
-          # KS/KP_hss_desc_enc
-          hs_y = private key of ephemeral x25519 keypair of hidden service
-          hs_Y = public key of ephemeral x25519 keypair of hidden service
-          # N_hs_desc_enc
           descriptor_cookie = descriptor cookie used to encrypt the descriptor
 
       And here is what the hidden service computes:
 
-          SECRET_SEED = x25519(hs_y, client_X)
+          SECRET_SEED = x25519(KS_hs_desc_ephem, KP_hsc_desc_enc)
           KEYS = KDF(N_hs_subcred | SECRET_SEED, 40)
           CLIENT-ID = fist 8 bytes of KEYS
           COOKIE-KEY = last 32 bytes of KEYS
@@ -1359,10 +1353,10 @@ Table of contents:
 
       [Exactly once]
 
-      A space-separated list of integers denoting CREATE2 cell format numbers
-      that the server recognizes. Must include at least ntor as described in
-      tor-spec.txt. See tor-spec section 5.1 for a list of recognized
-      handshake types.
+      A space-separated list of integers denoting CREATE2 cell HTYPEs
+      (handshake types) that the server recognizes. Must include at least
+      ntor as described in tor-spec.txt. See tor-spec section 5.1 for a list
+      of recognized handshake types.
 
      "intro-auth-required" SP types NL
 
diff --git a/tor-spec.txt b/tor-spec.txt
index b94add7..69ed12e 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -1022,7 +1022,7 @@ see tor-design.pdf.
        HLEN      (Server Handshake Data Len) [2 bytes]
        HDATA     (Server Handshake Data)     [HLEN bytes]
 
-   Recognized handshake types are:
+   Recognized HTYPEs (handshake types) are:
 
        0x0000  TAP  -- the original Tor handshake; see 5.1.3
        0x0001  reserved