prop224: Clarify the format of INTRODUCE1 cells

- Clarify how to distinguish between old and new style cells.
- Don't send the encryption key to the introduction point.

1 files changed, 43 insertions, 57 deletions

diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 4107599..097f442 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -1220,12 +1220,10 @@ Table of contents:
 
    An INTRODUCE1 cell has the following contents:
 
+     LEGACY_KEY_ID   [20 bytes]
      AUTH_KEY_TYPE   [1 byte]
      AUTH_KEY_LEN    [1 byte]
      AUTH_KEY        [AUTH_KEY_LEN bytes]
-     ENC_KEY_TYPE    [1 byte]
-     ENC_KEY_LEN     [1 byte]
-     ENC_KEY         [ENC_KEY_LEN bytes]
      N_EXTENSIONS    [1 byte]
      N_EXTENSIONS times:
        EXT_FIELD_TYPE [1 byte]
@@ -1233,31 +1231,43 @@ Table of contents:
        EXT_FIELD      [EXT_FIELD_LEN bytes]
      ENCRYPTED        [Up to end of relay payload]
 
-   [TODO: Should we have a field to determine the type of ENCRYPTED, or
-   should we instead assume that there is exactly one encryption key per
-   encryption method? The latter is probably safer.] [Agree -RD]
+   The LEGACY_KEY_ID field is used to distinguish between legacy and new style
+   INTRODUCE1 cells. In new style INTRODUCE1 cells, LEGACY_KEY_ID is 20 zero
+   bytes. Upon receiving an INTRODUCE1 cell, the introduction point checks the
+   LEGACY_KEY_ID field. If LEGACY_KEY_ID is non-zero, the INTRODUCE1 cell
+   should be handled as specified in rend-spec.txt.
 
-   Upon receiving an INTRODUCE1 cell, the introduction point checks
-   whether AUTH_KEY and ENC_KEY match a configured introduction
-   point authentication key and introduction point encryption key.  If
-   they do, the cell is relayed; if not, it is not.
+   AUTH_KEY_TYPE is defined as in [EST_INTRO]. Currently, the only value of
+   AUTH_KEY_TYPE for this cell is an Ed25519 public key [02].
 
-   (After checking AUTH_KEY and ENC_KEY and finding no match, the introduction
-   point should check to see whether a legacy hidden service is running whose
-   PK_ID is the first 20 bytes of AUTH_KEY.  If so, it behaves as in
-   rend-spec.txt.)
+   Upon receiving a INTRODUCE1 cell, the introduction point checks
+   whether AUTH_KEY matches the introduction point authentication key for an
+   active introduction circuit.  If so, the introduction point sends an
+   INTRODUCE2 cell with exactly the same contents to the service, and sends an
+   INTRODUCE_ACK response to the client.
 
-   The AUTH_KEY_TYPE is an Ed25519 public key (value [01]).
+3.2.2. Legacy formats [LEGACY-INTRODUCE1]
 
-   The ENC_KEY_TYPE is a truncated Curve25519 public key (value [03]). (This key
-   is safe to truncate, since all the keys are generated by the hidden service
-   host, and the ID is only valid relative to a single AUTH_KEY.)  The
-   ENCRYPTED field is as described in 3.3 below.
+   When a client is using a legacy introduction point, INTRODUCE1 cells should
+   be of the form:
 
-   To relay an INTRODUCE1 cell, the introduction point sends an
-   INTRODUCE2 cell with exactly the same contents.
+     LEGACY_KEYID_HASH    [20 bytes]
+     N_EXTENSIONS         [1 byte]
+     N_EXTENSIONS times:
+       EXT_FIELD_TYPE     [1 byte]
+       EXT_FIELD_LEN      [1 byte]
+       EXT_FIELD          [EXT_FIELD_LEN bytes]
+     ENCRYPTED            [Up to end of relay payload]
+
+   Here, LEGACY_KEYID_HASH is the hash of the introduction point legacy
+   encryption key that was included in the hidden service descriptor.
+
+   Because of limitations in older versions of Tor, the relay payload size for
+   these INTRODUCE1 cells must always be at least 246 bytes, or they will be
+   rejected as invalid. The ENCRYPTED field may contain padding to reach this
+   length.
 
-3.2.2. INTRODUCE_ACK cell format. [INTRO_ACK]
+3.2.3. INTRODUCE_ACK cell format. [INTRO_ACK]
 
    An INTRODUCE_ACK cell has the following fields:
 
@@ -1271,36 +1281,13 @@ Table of contents:
    Recognized status values are:
      [00 00] -- Success: cell relayed to hidden service host.
      [00 01] -- Failure: service ID not recognized
-     [00 02] -- Failure: key ID not recognized
-     [00 03] -- Bad message format
-
-3.2.3. Legacy formats [LEGACY-INTRODUCE1]
-
-   If a hidden service has listed a legacy introduction point in its
-   descriptor, INTRODUCE1 cells should be of the form:
-
-     LEGACY_KEYID_HASH    [20 bytes]
-     ENC_KEYID            [8 bytes]
-     N_EXTENSIONS         [1 byte]
-     N_EXTENSIONS times:
-       EXT_FIELD_TYPE     [1 byte]
-       EXT_FIELD_LEN      [1 byte]
-       EXT_FIELD          [EXT_FIELD_LEN bytes]
-     ENCRYPTED            [Up to end of relay payload]
-
-   Here, LEGACY_KEYID_HASH is the hash of the introduction point legacy
-   encryption key that was included in the hidden service descriptor.
-
-   Because of limitations in older versions of Tor, the relay payload size for
-   these INTRODUCE1 cells must always be at least 246 bytes, or they will be
-   rejected as invalid. [TODO: Do we need to pad with something?]
+     [00 02] -- Bad message format
 
 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2]
 
-   Upon receiving an INTRODUCE2 cell, the hidden service host checks
-   whether the AUTH_KEYID/AUTH_KEYID_HASH field and the ENC_KEYID fields
-   are as expected, and match the configured authentication and
-   encryption key(s) on that circuit.
+   Upon receiving an INTRODUCE2 cell, the hidden service host checks whether
+   the AUTH_KEY or LEGACY_KEYID_HASH field matches the keys for this
+   introduction circuit.
 
    The service host then checks whether it has received a cell with
    these contents before. If it has, it silently drops it as a
@@ -1335,7 +1322,6 @@ Table of contents:
           LSPEC  (Link specifier)                [LSLEN bytes]
       PAD        (optional padding)              [up to end of plaintext]
 
-
    Upon processing this plaintext, the hidden service makes sure that
    any required authentication is present in the extension fields, and
    then extends a rendezvous circuit to the node described in the LSPEC
@@ -1355,6 +1341,9 @@ Table of contents:
    extending to the rendezvous point. It must be of a type listed as
    supported in the hidden service descriptor.
 
+   When using a legacy introduction point, the INTRODUCE cells must be padded
+   to a certain length using the PAD field in the encrypted portion.
+
    Upon receiving a well-formed INTRODUCE2 cell, the hidden service host
    will have:
 
@@ -1426,11 +1415,8 @@ Table of contents:
    described in [FMT_INTRO1] above, we have
 
             AUTH_KEY_TYPE               [1 byte]
-            AUTH_KEY_LEN                [1 byte]
+            AUTH_KEY_LEN                [2 bytes]
             AUTH_KEY                    [AUTH_KEY_LEN bytes]
-            ENC_KEY_TYPE                [1 byte]
-            ENC_KEY_LEN                 [1 byte]
-            ENC_KEY                     [ENC_KEY_LEN bytes]
             N_EXTENSIONS                [1 bytes]
             N_EXTENSIONS times:
                EXT_FIELD_TYPE           [1 byte]
@@ -1534,8 +1520,7 @@ Table of contents:
         "hidserv-userauth-ed25519"
         Nonce       (same as above)
         Pubkey      (same as above)
-        AUTH_KEYID  (As in the INTRODUCE1 cell)
-        ENC_KEYID   (As in the INTRODUCE1 cell)
+        AUTH_KEY    (As in the INTRODUCE1 cell)
 
    The hidden service host checks this by seeing whether it recognizes
    and would accept a signature from the provided public key. If it
@@ -1639,7 +1624,8 @@ Table of contents:
 
    Old versions of Tor required that RENDEZVOUS cell payloads be exactly
    168 bytes long. All shorter rendezvous payloads should be padded to
-   this length with [00] bytes.
+   this length with random bytes, to make them difficult to distinguish from
+   older protocols at the rendezvous point.
 
 5. Encrypting data between client and host