[tor-commits] [torspec/master] prop224: Various improvements.
asn at torproject.org
asn at torproject.org
Sat Apr 9 11:15:20 UTC 2016
commit 397244ffecd091b841307c710aa8f8c3d6483818
Author: George Kadianakis <desnacked at riseup.net>
Date: Tue Mar 15 14:02:28 2016 +0200
prop224: Various improvements.
- Kill last remnants of TAP from the proposal.
- Replace SHA256 with SHA3-256 and our KDF with SHAKE.
- Make the INTRO_ESTABLISHED cell extensible.
- Improve the descriptor format a bit.
- Don't be ambiguous about "INTRODUCE" cells (pointed out by malekbr).
- Cleanup the scaling section.
---
proposals/224-rend-spec-ng.txt | 91 ++++++++++++++++--------------------------
1 file changed, 35 insertions(+), 56 deletions(-)
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 78b2071..dd76e36 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -137,11 +137,11 @@ Status: Draft
* Instantiate PK with Curve25519.
- * Instantiate H with SHA256. [TODO: really?]
+ * Instantiate H with SHA3-256.
- * Instantiate MAC with HMAC using H.
+ * Instantiate MAC(key=k, message=m) with H(k || m).
- * Instantiate KDF with HKDF using H.
+ * Instantiate KDF with HKDF using SHAKE-256.
For legacy purposes, we specify compatibility with older versions of
the Tor introduction point and rendezvous point protocols. These used
@@ -431,31 +431,12 @@ Status: Draft
1.5. In more detail: Scaling to multiple hosts
- [THIS SECTION IS UNFINISHED]
-
- In order to allow multiple hosts to provide a single hidden service,
- I'm considering two options.
-
- * We can have each server build an introduction circuit to each
- introduction point, and have the introduction points responsible
- for round-robining between these circuits. One service host is
- responsible for picking the introduction points and publishing
- the descriptors.
-
- * We can have servers choose their introduction points
- independently, and build circuits to them. One service host is
- responsible for combining these introduction points into a
- single descriptor.
-
- If we want to avoid having a single "master" host without which the
- whole service goes down (the "one service host" in the description
- above), we need a way to fail over from one host to another. We also
- need a way to coordinate between the hosts. This is as yet
- undesigned. Maybe it should use a hidden service?
-
- See [SCALING-REFS] for discussion on this topic.
-
- [TODO: Finalize this design.]
+ This design is compatible with our current approaches for scaling hidden
+ services. Specifically, hidden service operators can use onionbalance to
+ achieve high availability between multiple nodes on the HSDir
+ layer. Furthermore, operators can use proposal 255 to load balance their
+ hidden services on the introduction layer. See [SCALING-REFS] for further
+ discussions on this topic and alternative designs.
1.6. In more detail: Backward compatibility with older hidden service
protocols
@@ -839,13 +820,17 @@ Status: Draft
The format for a hidden service descriptor is as follows, using the
meta-format from dir-spec.txt.
- "hs-descriptor" SP version-number SP certificate NL
+ "hs-descriptor" SP version-number NL
[At start, exactly once.]
The version-number contains a positive integer indicating the version
of the descriptor. Current version is "3".
+ "descriptor-signing-key-cert" SP certificate NL
+
+ [Exactly once.]
+
The 'certificate' field contains a certificate in the format from
proposal 220, with the short-term ed25519 descriptor-signing key
for the replica, signed by the blinded public key for the replica.
@@ -1089,7 +1074,7 @@ Status: Draft
[00, 01] -- Reserved for legacy introduction cells; see
[LEGACY_EST_INTRO below]
- [02] -- Ed25519; HMAC-SHA256.
+ [02] -- Ed25519; SHA3-256.
[FF] -- Reserved for maintenance messages on existing
circuits; see MAINT_INTRO below.
@@ -1155,22 +1140,14 @@ Status: Draft
The KEY field is a ASN1-encoded RSA public key.
- The HANDSHAKE_AUTH field contains the SHA1 digest of (KH |
- "INTRODUCE").
+ The HANDSHAKE_AUTH field contains the SHA1 digest of (KH | "INTRODUCE").
The SIG field contains an RSA signature, using PKCS1 padding, of all
earlier fields.
- Note that since the relay payload itself may be no more than 498
- bytes long, the KEY_LEN field can never have a first byte other
- than [00] or [01]. These values are used to distinguish legacy
- ESTABLISH_INTRO cells from newer ones.
-
- Older versions of Tor always use a 1024-bit RSA key for these
- introduction authentication keys.
-
- Newer hidden services MAY use RSA keys up 1904 bits. Any more than
- that will not fit in a RELAY cell payload.
+ Older versions of Tor always use a 1024-bit RSA key for these introduction
+ authentication keys. Newer hidden services MAY use RSA keys up 1904
+ bits. Any more than that will not fit in a RELAY cell payload.
3.1.3. Managing introduction circuits [MAINT_INTRO]
@@ -1242,12 +1219,16 @@ Status: Draft
3.1.4. Acknowledging establishment of introduction point [INTRO_ESTABLISHED]
- After setting up an introduction circuit, the introduction point
- reports its status back to the hidden service host with an empty
- INTRO_ESTABLISHED cell.
+ After setting up an introduction circuit, the introduction point reports its
+ status back to the hidden service host with an INTRO_ESTABLISHED cell.
+
+ The INTRO_ESTABLISHED cell has the following contents:
- [TODO: make this cell type extensible. It should be able to include
- data if that turns out to be needed.]
+ N_EXTENSIONS [1 byte]
+ N_EXTENSIONS times:
+ EXT_FIELD_TYPE [1 byte]
+ EXT_FIELD_LEN [1 byte]
+ EXT_FIELD [EXT_FIELD_LEN bytes]
3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1]
@@ -1400,10 +1381,9 @@ Status: Draft
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.
- The ONION_KEY_TYPE field is one of:
+ The ONION_KEY_TYPE field is:
- [01] TAP-RSA-1024: ONION_KEY is 128 bytes long.
- [02] NTOR: ONION_KEY is 32 bytes long.
+ [01] NTOR: ONION_KEY is 32 bytes long.
The ONION_KEY field describes the onion key that must be used when
extending to the rendezvous point. It must be of a type listed as
@@ -1450,14 +1430,13 @@ Status: Draft
Notation here is as in section 5.1.4 of tor-spec.txt, which defines
the ntor handshake.
- The PROTOID for this variant is
- "hidden-service-ntor-curve25519-sha256-1". Define the tweak value
- t_hsenc, and the tag value m_hsexpand as:
+ The PROTOID for this variant is "tor-hs-ntor-curve25519-sha3-256-1".
+ We also use the following tweak values:
t_hsenc = PROTOID | ":hs_key_extract"
m_hsexpand = PROTOID | ":hs_key_expand"
- To make an INTRODUCE cell, the client must know a public encryption
+ To make an INTRODUCE1 cell, the client must know a public encryption
key B for the hidden service on this introduction circuit. The client
generates a single-use keypair:
x,X = KEYGEN()
@@ -1560,7 +1539,7 @@ Status: Draft
3.4.1. Password-based authentication.
To authenticate with a password, the user must include an extension
- field in the encrypted part of the INTRODUCE cell with an
+ field in the encrypted part of the INTRODUCE1 cell with an
EXT_FIELD_TYPE type of [01] and the contents:
Username [00] Password.
@@ -1573,7 +1552,7 @@ Status: Draft
3.4.2. Ed25519-based authentication.
To authenticate with an Ed25519 private key, the user must include an
- extension field in the encrypted part of the INTRODUCE cell with an
+ extension field in the encrypted part of the INTRODUCE1 cell with an
EXT_FIELD_TYPE type of [02] and the contents:
Nonce [16 bytes]
More information about the tor-commits
mailing list