commit 0cfe03bb4890463d12c9979b1c50eac38236ead4 Author: Roger Dingledine arma@torproject.org Date: Sun May 8 21:21:24 2016 -0400
questions from when i was reading through it --- proposals/224-rend-spec-ng.txt | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 8bcd9f8..989c741 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -152,6 +152,7 @@ Status: Draft 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]
As in [proposal 220], all signatures are generated not over strings themselves, but over those strings prefixed with a distinguishing @@ -390,6 +391,9 @@ Status: Draft 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]
The final level of access control happens at the server itself, which may decide to respond or not respond to the client's request @@ -682,6 +686,7 @@ Status: Draft
hsdir_spread_accept = an integer in range [1,128] with default value 12. +[XXX I think I obsoleted this spread_accept notion? -RD]
To determine where a given hidden service descriptor will be stored in a given period, after the blinded public key for that period is @@ -706,6 +711,7 @@ Status: Draft 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]
Finally, for replicanum in 1...hsdir_n_replicas, the hidden service host uploads descriptors to the first hsdir_spread_store nodes whose @@ -833,6 +839,9 @@ Status: Draft
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 @@ -896,7 +905,6 @@ Status: Draft the hidden service host does not need to have its private blinded key online.
- 2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA]
The encrypted part of the hidden service descriptor is encrypted and @@ -951,6 +959,8 @@ Status: Draft '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]
"introduction-point" SP link-specifiers NL
@@ -1083,6 +1093,11 @@ Status: Draft [TODO: The above will work fine with what we do today, but it will do quite badly if we ever freak out and want to go back to RSA2048 or bigger. Do we care?] + [Do we lose much by making AUTH_KEY_LEN and SIGLEN 2 bytes each? Or, + even crazier, do we lose much by making those two variable sizes, + defined by whichever value of AUTH_KEY_TYPE you pick? I guess we + don't know how big it is if we don't recognize the key type, but we + are already planning to refuse the intro request then. -RD]
3.1.2. Registering an introduction point on a legacy Tor node [LEGACY_EST_INTRO]
@@ -1090,6 +1105,8 @@ Status: Draft 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:
@@ -1127,6 +1144,10 @@ Status: Draft EXT_FIELD_LEN [1 byte] EXT_FIELD [EXT_FIELD_LEN bytes]
+ [Worth mentioning that old-school Tor relays send back an empty + payload here? Or, even better, not mentioning it if we simplify + 3.1.2 to "don't do that". -RD] + 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1]
In order to participate in the introduction protocol, a client must @@ -1164,7 +1185,7 @@ Status: Draft
[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.] + encryption method? The latter is probably safer.] [Agree -RD]
Upon receiving an INTRODUCE1 cell, the introduction point checks whether AUTH_KEY and ENC_KEY match a configured introduction