[tor-commits] [torspec/master] questions from when i was reading through it

[arma@xxxxxxxxxxxxxx]

commit 0cfe03bb4890463d12c9979b1c50eac38236ead4
Author: Roger Dingledine <arma@xxxxxxxxxxxxxx>
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

_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits