On 12 Jun (08:18:33), David Goulet wrote: After some days on tor-dev@ and a round of review, this is now a Draft in tor-spec.txt. https://gitweb.torproject.org/torspec.git/tree/proposals/305-establish-intro-dos-defense-extention.txt Cheers! David > Filename: 305-establish-intro-dos-defense-extention.txt > Title: ESTABLISH_INTRO Cell DoS Defense Extension > Author: David Goulet, George Kadianakis > Created: 06-June-2019 > Status: Draft > > 0. Abstract > > We propose introducing a new cell extension to the onion service version 3 > ESTABLISH_INTRO cell in order for a service operator to send directices to > the introduction point. > > 1. Introduction > > The idea behind this proposal is to provide a way for a service operator to > give to the introduction points Denial of Service (DoS) defense parameters > through the ESTABLISH_INTRO cell. > > We are currently developing onion service DoS defenses at the introduction > point layer which for now has consensus parameter values for the defenses' > knobs. This proposal would allow the service operator more flexibility for > tuning these knobs and/or future parameters. > > 2. Proposal > > We introduce a new extention to the ESTABLISH_INTRO cell. The EXTENSIONS > field will be leveraged and a new protover will be introduced to reflect > that change. > > As a reminder, this is the content of an ESTABLISH_INTRO cell (taken from > rend-spec-v3.txt section 3.1.1): > > AUTH_KEY_TYPE [1 byte] > AUTH_KEY_LEN [2 bytes] > AUTH_KEY [AUTH_KEY_LEN bytes] > N_EXTENSIONS [1 byte] > N_EXTENSIONS times: > EXT_FIELD_TYPE [1 byte] > EXT_FIELD_LEN [1 byte] > EXT_FIELD [EXT_FIELD_LEN bytes] > HANDSHAKE_AUTH [MAC_LEN bytes] > SIG_LEN [2 bytes] > SIG [SIG_LEN bytes] > > We propose a new EXT_FIELD_TYPE value: > > [01] -- DOS_PARAMETERS. > > If this flag is set, the extension should be used by the > introduction point to learn what values the denial of service > subsystem should be using. > > The EXT_FIELD content format is: > > N_PARAMS [1 byte] > N_PARAMS times: > PARAM_TYPE [1 byte] > PARAM_VALUE [8 byte] > > The PARAM_TYPE proposed values are: > > [01] -- DOS_INTRODUCE2_RATE_PER_SEC > The rate per second of INTRODUCE2 cell relayed to the service. > > [02] -- DOS_INTRODUCE2_BURST_PER_SEC > The burst per second of INTRODUCE2 cell relayed to the service. > > The PARAM_VALUE size is 8 bytes in order to accomodate 64bit values > (uint64_t). It MUST match the specified limit for the following PARAM_TYPE: > > [01] -- Min: 0, Max: INT_MAX > [02] -- Min: 0, Max: INT_MAX > > A value of 0 means the defense is disabled which has precedence over the > network wide consensus parameter. > > In this case, if the rate per second is set to 0 (param 0x01) then the > burst value should be ignored. And vice-versa, if the burst value is 0, > then the rate value should be ignored. In other words, setting one single > parameter to 0 disables the INTRODUCE2 rate limiting defense. > > 3. Protocol Version > > We introduce a new protocol version in order for onion service that wants > to specifically select introduction points supporting this new extension. > But also, it should be used to know when to send this extension or not. > > The new version for the "HSIntro" protocol is: > > "5" -- support ESTABLISH_INTRO cell DoS parameters extension for onion > service version 3 only. > > 4. Configuration Options > > We also propose new torrc options in order for the operator to control > those values passed through the ESTABLISH_INTRO cell. > > "HiddenServiceEnableIntroDoSDefense 0|1" > > If this option is set to 1, the onion service will always send to the > introduction point denial of service defense parameters regardless of > what the consensus enables it or not. The value will be taken from > the consensus and if not present, the default values will be used. > (Default: 0) > > "HiddenServiceEnableIntroDoSRatePerSec N sec" > > Controls the introduce rate per second the introduction point should > impose on the introduction circuit. > (Default: 25, Min: 0, Max: 4294967295) > > "HiddenServiceEnableIntroDoSBurstPerSec N sec" > > Controls the introduce burst per second the introduction point should > impose on the introduction circuit. > (Default: 200, Min: 0, Max: 4294967295) > > They respectively control the parameter type 0x01 and 0x02 in the > ESTABLISH_INTRO cell detailed in section 2. > > The default values of the rate and burst are taken from ongoing anti-DoS > implementation work [1][2]. They aren't meant to be defined with this > proposal. > > 5. Security Considerations > > Using this new extension leaks to the introduction point the service's tor > version. This could in theory help any kind of de-anonymization attack on a > service since at first it partitions it in a very small group of running > tor. > > Furthermore, when the first tor version supporting this extension will be > released, very few introduction points will be updated to that version. > Which means that we could end up in a situation where many services want to > use this feature and thus will only select a very small subset of relays > supporting it overloading them but also making it an easier vector for an > attacker that whishes to be the service introduction point. > > For the above reasons, we propose a new consensus parameters that will > provide a "go ahead" for all service out there to start using this > extension only if the introduction point supports it. > > "enable_establish_intro_dos_extension" > > If set to 1, this makes tor start using this new proposed extension > if available by the introduction point (looking at the new protover). > > This parameter should be switched on when a majority of relays have > upgraded to a tor version that supports this extension for which we believe > will also give enough time for most services to move to this new stable > version making the anonymity set much bigger. > > We propose to add a torrc option to ignore this parameter and force tor to > select introduction points supporting this extension which will > effectively, in the beginning, toss away these security considerations. > > We believe that there are services that do not care about anonymity on the > service side and thus could benefit from this feature right away if they > wish to use it. > > References: > > [1] https://lists.torproject.org/pipermail/tor-dev/2019-May/013837.html > [2] https://trac.torproject.org/15516 > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- 7gvISGYHFNIK7QwNC3ESEsvXh8l/OzdFYlwyc0G7WWQ=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev