[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] prop224: Various improvements and XXX removals.
commit c4d470333bc5735a60b6282ff8d97ac952309fdf
Author: George Kadianakis <desnacked@xxxxxxxxxx>
Date: Tue May 10 10:53:05 2016 -0400
prop224: Various improvements and XXX removals.
- Replace AES128-CTR with AES256.
- Use relay ed25519 identity keys to create the HSDir hash ring.
- Accept 0 introduction points in descriptors.
---
proposals/224-rend-spec-ng.txt | 60 ++++++++++++++++--------------------------
1 file changed, 22 insertions(+), 38 deletions(-)
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 097f442..408a982 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -188,7 +188,7 @@ Table of contents:
As a first pass, I suggest:
- * Instantiate STREAM with AES128-CTR. [TODO: or ChaCha20?]
+ * Instantiate STREAM with AES256-CTR.
* Instantiate SIGN with Ed25519 and the blinding protocol in
[KEYBLIND].
@@ -204,9 +204,7 @@ Table of contents:
For legacy purposes, we specify compatibility with older versions of
the Tor introduction point and rendezvous point protocols. These used
RSA1024, DH1024, AES128, and SHA1, as discussed in
- rend-spec.txt. Except as noted, all RSA keys MUST have exponent
- values of 65537.
- [XXX -- is this last sentence new? I think we don't require it now. -RD]
+ rend-spec.txt.
As in [proposal 220], all signatures are generated not over strings
themselves, but over those strings prefixed with a distinguishing
@@ -441,13 +439,9 @@ Table of contents:
of the hidden service descriptor. The encryption key for these is
derived from the service's credential.
- In order to make an introduction point send a request to the server,
- the client must know the introduction point and know the service's
- per-introduction-point authentication key from the hidden service
- descriptor.
- [XXX what exactly does the intro point check then? Seems like the
- intro point should be able to send a cell down the circuit to the
- service, even if the service doesn't like the cell. -RD]
+ In order to make the introduction point send a rendezvous request to the
+ service, the client needs to use the per-introduction-point authentication
+ key found in the hidden service descriptor.
The final level of access control happens at the server itself, which
may decide to respond or not respond to the client's request
@@ -523,7 +517,6 @@ Table of contents:
compromised, the adversary can only impersonate it for a limited
period of time (depending on how many signing keys were generated
in advance).
- [TODO: Define revocation mechanism?]
It's important to not send the private part of the blinded signing
key to the Hidden Service since an attacker can derive from it the
@@ -754,14 +747,13 @@ Table of contents:
Then, for each node listed in the current consensus with the HSDirV3 flag,
we compute a directory index for that node as:
- hsdir_index(node) = H("node-idx" | node_identity_digest |
+ hsdir_index(node) = H("node-idx" | node_identity |
shared_random_value |
INT_8(period_num) )
where shared_random_value is the shared value generated by the authorities
- in section [PUB-SHAREDRANDOM], and node_identity_digest is a SHA1 digest of
- the node's RSA public key as described in tor-spec.txt.
-[XXX Maybe include a sentence about why SHA1 isn't scary here? -RD]
+ in section [PUB-SHAREDRANDOM], and node_identity is the ed25519 identity key
+ of the node.
Finally, for replicanum in 1...hsdir_n_replicas, the hidden service
host uploads descriptors to the first hsdir_spread_store nodes whose
@@ -855,10 +847,6 @@ Table of contents:
/tor/rendezvous3/<z> where z is a base-64 encoding of the hidden
service's blinded public key.
- [TODO: raw base64 is not super-nice for URLs, since it can have
- slashes. We already use it for microdescriptor URLs, though. Do we
- care here?]
-
These requests must be made anonymously, on circuits not used for
anything else.
@@ -880,18 +868,15 @@ Table of contents:
2.3.1. Client behavior in the absense of shared random values
If the previous or current shared random value cannot be found in a
- consensus, then Tor clients need to generate their own random value for use
- when choosing HSDirs.
+ consensus, then Tor clients and services need to generate their own random
+ value for use when choosing HSDirs.
- To do so, clients use:
+ To do so, Tor clients and services use:
SRV = HMAC("shared-random-disaster", TIME_PERIOD_NUM)
as the SRV for time period TIME_PERIOD_NUM.
-[Ok, this says clients. What do servers do? The same, right? Or should
- we let services choose to drop off in the disaster case? -RD]
-
2.3.2. Hidden services and changing shared random values
It's theoretically possible that the consensus shared random values will
@@ -1008,9 +993,7 @@ Table of contents:
able to contact the host. Recognized types are: 'password' and
'ed25519'. See [INTRO-AUTH] below.
- At least once:
-[XXX Why not permit descriptors that list 0 intro points? I think
- they're permitted in the legacy rend design. -RD]
+ Followed by zero or more introduction points as follows:
"introduction-point" SP link-specifiers NL
@@ -1155,8 +1138,6 @@ Table of contents:
cell, first documented in rend-spec.txt. New hidden service hosts
must use this format when establishing introduction points at older
Tor nodes that do not support the format above in [EST_INTRO].
- [If we roll out intro-point-side support early enough, then service
- hosts can simply avoid making intro points to old relays? -RD]
In this older protocol, an ESTABLISH_INTRO cell contains:
@@ -1372,6 +1353,8 @@ Table of contents:
3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA]
+ [TODO: relocate this]
+
This is a variant of the ntor handshake (see tor-spec.txt, section
5.1.4; see proposal 216; and see "Anonymity and one-way
authentication in key-exchange protocols" by Goldberg, Stebila, and
@@ -1544,12 +1527,13 @@ Table of contents:
4.1. Establishing a rendezvous point [EST_REND_POINT]
- The client sends the rendezvous point a
- RELAY_COMMAND_ESTABLISH_RENDEZVOUS cell containing a 20-byte value.
+ The client sends the rendezvous point a RELAY_COMMAND_ESTABLISH_RENDEZVOUS
+ cell containing a 20-byte value.
+
RENDEZVOUS_COOKIE [20 bytes]
Rendezvous points MUST ignore any extra bytes in an
- ESTABLISH_RENDEZVOUS message. (Older versions of Tor did not.)
+ ESTABLISH_RENDEZVOUS cell. (Older versions of Tor did not.)
The rendezvous cookie is an arbitrary 20-byte value, chosen randomly
by the client. The client SHOULD choose a new rendezvous cookie for
@@ -1557,10 +1541,10 @@ Table of contents:
use on an existing circuit, the rendezvous point should reject it and
destroy the circuit.
- Upon receiving an ESTABLISH_RENDEZVOUS cell, the rendezvous point
- associates the cookie with the circuit on which it was sent. It
- replies to the client with an empty RENDEZVOUS_ESTABLISHED cell to
- indicate success. [TODO: make this extensible]
+ Upon receiving an ESTABLISH_RENDEZVOUS cell, the rendezvous point associates
+ the cookie with the circuit on which it was sent. It replies to the client
+ with an empty RENDEZVOUS_ESTABLISHED cell to indicate success. Clients MUST
+ ignore any extra bytes in a RENDEZVOUS_ESTABLISHED cell.
The client MUST NOT use the circuit which sent the cell for any
purpose other than rendezvous with the given location-hidden service.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits