diff options
author | Mike Perry <mikeperry-git@torproject.org> | 2016-01-27 13:47:24 -0800 |
---|---|---|
committer | George Kadianakis <desnacked@riseup.net> | 2018-05-24 12:39:37 +0300 |
commit | d0bbdb3ccb19f1821670f6684eaf1c609281f2e8 (patch) | |
tree | 4dc5c7d5b261087844601549ca8f1c1bc13abdb4 /proposals/247-hs-guard-discovery.txt | |
parent | a19d0bf1f05e1108805cfeec8a545d6ee85cb399 (diff) | |
download | torspec-d0bbdb3ccb19f1821670f6684eaf1c609281f2e8.tar.gz torspec-d0bbdb3ccb19f1821670f6684eaf1c609281f2e8.zip |
Prop 247: Some notes from mailinglist discussion
Diffstat (limited to 'proposals/247-hs-guard-discovery.txt')
-rw-r--r-- | proposals/247-hs-guard-discovery.txt | 35 |
1 files changed, 33 insertions, 2 deletions
diff --git a/proposals/247-hs-guard-discovery.txt b/proposals/247-hs-guard-discovery.txt index 51e5248..99b196c 100644 --- a/proposals/247-hs-guard-discovery.txt +++ b/proposals/247-hs-guard-discovery.txt @@ -103,6 +103,25 @@ Status: Draft Each node's rotation time is tracked independently, to avoid disclosing the rotation times of the primary and second-level guards. + XXX: IP and RP actually need to be separate 4th hops. On the server side, + IP should be separate to better unlink IP from the 3rd layer guards, + and on the client side, the RP needs to come from the full network to + avoid cross-visit linkability. So it's seven proxies all teh time... + + XXX: What about hsdir fetch? to avoid targeting and visit linkability, + it needs an emphemeral hop too.. Unless we believe that linkability is low? + It is lower than IP linkability, since the hsdescs can be cached for a bit. + But if we are worried about visit linkability, then client should also add + an extra ephemeral hop during IP visits, making that circuit 8 hops long... + + XXX: Emphemeral hops for service side before RP? + + XXX: Really crazy idea: We can provide multiple path security levels. + We could have full 4 hops, or combine Layer2+Layer3, or combine Layer1+Layer2 + and Layer3+Layer4 for lower-security HS circs.. + + XXX: update the load balancing proposal with the outcome of this :/ + XXX how should proposal 241 ("Resisting guard-turnover attacks") be applied here? @@ -504,6 +523,14 @@ Status: Draft be used for the second and third-level nodes at all, and to allow the primary guard to be chosen as a rend point. + XXX: Dgoulet suggested using arbitrary subsets here rather than the + no Guard-flag restriction, esp since Layer2 inference is still a + possibility. + + XXX: If a Guard-flagged node is chosen for the alls IP or RP, raise + protocolerror. Refuse connection. Or allow our guard/other nodes in + IP/RP.. + Additionally, in order to further limit the exposure of secondary guards to sybil attacks, the bin position of the third-level guards should be stable over long periods of time. When choosing third-level guards, these @@ -517,8 +544,8 @@ Status: Draft 4.4. Denial of service Since it will be fairly trivial for the adversary to enumerate the - current set of rend nodes for a hidden service, denial of service - becomes a serious risk for Vanguard users. + current set of third-layer guards for a hidden service, denial of + service becomes a serious risk for Vanguard users. For this reason, it is important to support a large number of third-level guards, to increase the amount of resources required to @@ -532,6 +559,10 @@ Status: Draft unwise to simply replace unresponsive third-level guards that fail to complete circuits, as this will accelerate the Sybil attack. +4.5. Path Bias + +XXX: Re-use Prop#259 here. + 5. Performance considerations |