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.

1 files 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.