[tor-commits] [torspec/master] prop224: Clarify the format of INTRODUCE1 cells
asn at torproject.org
asn at torproject.org
Thu May 12 18:27:44 UTC 2016
commit 8731baffa869894416aa0d09f499298ed05a87f4
Author: John Brooks <special at 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
More information about the tor-commits
mailing list