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