[tor-commits] [torspec/main] Improve vanguard-lite proposal.

[asn@xxxxxxxxxxxxxx]

commit aec36da1cdd75978c7a323739d592a11e0354c4a
Author: George Kadianakis <desnacked@xxxxxxxxxx>
Date:   Tue Jul 20 13:46:53 2021 +0300

    Improve vanguard-lite proposal.
    
    - Mention that an extra hop is added on service-side intro circs
    - Add circuit path length diagram
    - Mention max number of L2 guards
    - Add control port events to control spec
---
 control-spec.txt                |  2 ++
 proposals/332-vanguards-lite.md | 26 ++++++++++++++++++++------
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/control-spec.txt b/control-spec.txt
index 70f9b20..9b51715 100644
--- a/control-spec.txt
+++ b/control-spec.txt
@@ -3097,6 +3097,8 @@
     "DOWN" -- The guard now seems to be unreachable.
     "BAD"  -- Because of flags set in the consensus and/or values in the
               configuration, this node is now unusable as a guard.
+    "BAD_L2" -- This layer2 guard has expired or got removed from the
+              consensus. This node is removed from the layer2 guard set.
     "GOOD" -- Because of flags set in the consensus and/or values in the
               configuration, this node is now usable as a guard.
 
diff --git a/proposals/332-vanguards-lite.md b/proposals/332-vanguards-lite.md
index 3971b75..1e567c5 100644
--- a/proposals/332-vanguards-lite.md
+++ b/proposals/332-vanguards-lite.md
@@ -23,22 +23,36 @@ Status: Draft
   - No third layer of guards is used.
   - The Layer2 lifetime uses the max(x,x) distribution with a minimum of one
     day and maximum of 12 days. This makes the average lifetime approximately a
-    week. We let NUM_LAYER2_GUARDS=4.
+    week.
+  - We let NUM_LAYER2_GUARDS=4. We also introduce a consensus parameter
+    `guard-hs-l2-number` that controls the number of layer2 guards (with a
+    maximum of 19 layer2 guards).
   - We don't write guards on disk. This means that the guard topology resets
     when tor restarts.
 
-  By avoiding a third-layer of guards we reduce the linkability issues
-  of Proposal 292, which means that we don't have to add an extra hop on top of
-  our paths. This simplifies engineering.
+  By avoiding a third-layer of guards we avoid most of the linkability issues
+  of Proposal 292. This means that we don't add an extra hop on top of most of
+  our onion service paths, which increases performance. However, we do add an
+  extra middle hop at the end of service-side introduction circuits to avoid
+  linkability of L2s by the intro points.
 
-# 2. Rotation Period Analysis
+  This is how onion service circuits look like with this proposal:
+
+	 Client rend:   C -> G -> L2 -> Rend
+	 Client intro:  C -> G -> L2 -> M -> Intro
+	 Client hsdir:  C -> G -> L2 -> M -> HSDir
+	 Service rend:  C -> G -> L2 -> M -> Rend
+	 Service intro: C -> G -> L2 -> M -> Intro
+	 Service hsdir: C -> G -> L2 -> M -> HSDir
+
+# 3. Rotation Period Analysis
 
   From the table in Section 3.1 of Proposal 292, with NUM_LAYER2_GUARDS=4 it
   can be seen that this means that the Sybil attack on Layer2 will complete
   with 50% chance in 18*7 days (126 days) for the 1% adversary, 4*7 days (one
   month) for the 5% adversary, and 2*7 days (two weeks) for the 10% adversary.
 
-# 3. Tradeoffs from Proposal 292
+# 4. Tradeoffs from Proposal 292
 
   This proposal has several advantages over Proposal 292:
 



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