Hello,
thanks for you mail. my comments are below.
On 1/15/20 6:17 PM, juanjo wrote:
Hi, thanks for working on it.
At first I thought about using a PoW on the Introduction Point (I.P.) side.
Maybe a dynamic PoW? I mean only ask for PoW under load (Hidden services sets the INTRO1s/second on the I.P.) or ask for every new circuit. From what I know this would most likely require a more than 1-RTT
(interactive) introduction protocol. I think we definitely want to avoid that.
Then I thought that we need to fix the Rendezvous verification issue too. We do not verify if the client/user/attacker actually opened a circuit to the Rend point. And I thought we could make the Rend sing a message and the I.P verify the signature before sending the INTRO2 to the HS.
Such a signature would have to be zero knowledge. Otherwise we would leak the chosen RP to the IP and make deanonymization more likely. Designing an unforgeable proof of rendezvous is non-trivial (even if it is was verified by the service and not the IP), because we have to assume that adversaries run their own relays. Therefore they could most likely precompute/forge these proofs of rendezvous. Of course, we could try and cache which RPs have been used, but this seems a lot of work for relatively little security benefits. I doubt that this approach is suitable to discourage resourceful adversaries from DoSing services.
But now I think we need to merge designs and make just one proposal fixing both problems at the same time.
If we don't want to make a PoW for every new circuit, we could make the client generate a private Identity (KeyPair) mixed with some sort of PoW, generating it for every HS a client want to connect. This way we only make PoW for each onion and the IP can have a replay cache (or something like that) with each identity and the last time it requested a new circuit. We can better control with this way the number of individual clients and we "save the planet" by not making a PoW for each new circuit. (Maybe this approach is what your are working at with the "token based approach").
I believe, we should avoid making different connections to an onion service by the same user linkable by the IP/service as this would turn anonymity into pseudonymity and therefore ease user identification. Of course, there are crypto schemes that allow us to use anonymous credentials/ authentication. Unfortunately, I am not sure how such anonymous credentials could be useful for DoS mitigation. We would somehow need a mechanism to detect misbehavior and revoke the credentials or limit their use to a certain number of authentications. I am not sure, how this can be done if different authentications using the same credentials are truely unlinkable.
Sorry for my english...
El 13/1/20 a las 13:39, Valentin Franck escribió:
Hello tor-devs,
I am currently working on a DoS mitigation system aiming to protect the availability of onion services flooded with INTRO2 cells. My idea is using a (Privacy Pass like) token based approach as suggested in https://trac.torproject.org/projects/tor/ticket/31223#comment:6
For the evaluation of a first prototype I would like to compare CPU usage times at the onion service when a) launching a rendezvous circuit and b) validating a (potentially invalid) token. Is there an easy way, to measure the CPU time a service spends for all operations triggered when launching a new rendezvous circuit? Has somebody done that before? Basically, I want to measure how much CPU time we save, if we do not launch the rendezvous circuit. So far I have identified the following functions: launch_rendezvous_point_circuit() and service_rendezvous_circ_has_opened(). I understand that there is more operations involved for building new circuits, since circuits are built hop by hop. How can I identify all relevant functions triggered after launching the rendezvous circuit and include them in my measurements?
Once I have some reliable results I will provide you with more information on what I am doing and how it is working so far.
Cheers Valentin
This is my first post on this list :-). So have mercy, if I overlooked resources to answer my question. Also, I am only beginning to familiarize myself with the existing code base.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev