On 13 Jun (10:35:34), teor wrote: > Hi, [snip] > >> 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 > > This is ambiguous: > * the value is 8 bytes long > * the length of the maximum is unspecified: is it 4 bytes, 8 bytes, signed, or > unsigned? > * the torrc default is unsigned 4 bytes: UINT32_MAX Yeah my goal was to max it out to the torrc but signed because our consensus param are int32_t (networkstatus_get_param()). I've pushed a fixup to clarify all this. I've actually put the INT32_MAX value in there instead of just a "macro" :). > > > How would this new addition to the cell impact the size of the cell? How > > much free space do we have for additional features to this cell (e.g. to > > do the PoW stuff of the other thread)? > > > >> A value of 0 means the defense is disabled which has precedence over the > >> network wide consensus parameter. > > Let's say "any value has precedence over the network wide consensus > parameter". Otherwise it's unclear if 0 is a special value or not. Indeed. Corrected. > > >> 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. > > What happens if burst is less than rate? I've clarified. > > > I think it could be cool to add a discussion section where we introduce > > a new cell from the intro to the service which informs the service that > > rate limiting limits have been hit. So that there is a way for the > > service to get feedback that it's under attack or capped by > > limits. Otherwise, there is simply no way to learn it. > > > > This can be a later feature fwiw. > > > >> 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 > > if the intro point protocol supports them > > >> regardless of > >> what the consensus enables it or not. The value will be taken from > > * values will be taken from > > the HiddenServiceEnableIntroDoSRatePerSec and > HiddenServiceEnableIntroDoSBurstPerSec torrc options, then Fixed. > > >> 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) > > Doesn't the default come from the consensus, and then the hard-coded > default? If explicitely set, the torrc options always win over the consensus param. Thus, the default values are only taken if the consensus param aren't present. I've clarified. > > Also see my notes about ambiguous size/signed maximums above. > > >> "HiddenServiceEnableIntroDoSBurstPerSec N sec" > >> > >> Controls the introduce burst per second the introduction point should > >> impose on the introduction circuit. > >> (Default: 200, Min: 0, Max: 4294967295) > > Doesn't the default come from the consensus, and then the hard-coded > default? > > Also see my notes about ambiguous size/signed maximums above. Fixed. > > >> 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. > >> > > > > Interesting idea. > > > > I'm not that worried about the service leaking its version to the intro, > > but I am worried about all attacked services saturating the few upgraded > > intro points, so I agree that such a switch makes sense. > > > >> For the above reasons, we propose a new consensus parameters that will > > * parameter > > >> 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" > > Can we just call it HiddenServiceEnableIntroDoSDefense? > > It's weird naming some DoS consensus parameters in snake_case, and > others in CamelCase. And it's also weird having different names for > torrc options and consensus parameters. Yes good idea. And this is how we did things with the DoS subsystem as well to match both in the consensus and torrc. > > >> 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 > > HiddenServiceEnableIntroDoSDefense? > > >> 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. > > I think we also need consensus parameters for HiddenServiceEnableIntroDoSRatePerSec and > HiddenServiceEnableIntroDoSBurstPerSec. We do, it is just part of another piece of work from ticket #15516. Everything has been fixed and pushed! Thanks! David -- NYhJAL29Sx8P3VP6lGX7k5jnjujtvQexLKt/rMno1u8=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev