commit c4d470333bc5735a60b6282ff8d97ac952309fdf Author: George Kadianakis <desnacked@riseup.net> 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.