#33712: Design a PoW/credential scheme for HS DoS defence
-------------------------------------------------+-------------------------
Reporter: asn | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs, tor-dos, network-team- | Actual Points:
roadmap-2020Q1, network-health, research |
Parent ID: #31223 | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by arma):
I think I arrive at the same conclusions as Mike, but for different
reasons.
To me, the reason to focus on the "client to service" defense is that I
believe whatever design we pick is going to need to have a "client to
service" component, i.e. I don't think we can solve this problem solely
with a "client to intro point" component. So if we need client-to-service,
let's try to construct a system where that is sufficient.
I'm not much worried about time-to-upgrade. Let's think about the eventual
result we want, and then get ourselves there. A few months for upgrades
will pass before we know it, and if we have an important update that needs
more relays to upgrade, we can ask them to do it.
Or, to rephrase: I currently think that client-to-service is the right
area to focus on, because we're going to need it for the eventual
solution, not because we have to constrain ourselves to solutions we can
deploy this week. If we have a solution we like that involves parts of the
network upgrading, let's be sure to keep it on the table so we don't
accidentally rule out our best future just because it would be more
logistics work to get there.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33712#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
