[tor-dev] Evaluating rendezvous circuit build up CPU usage

[Valentin Franck]

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 at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev