commit 8731baffa869894416aa0d09f499298ed05a87f4 Author: John Brooks special@torproject.org Date: Mon May 9 18:45:35 2016 -0400
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. --- proposals/224-rend-spec-ng.txt | 100 ++++++++++++++++++----------------------- 1 file 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