Re: [tor-dev] Shortcomings of the pluggable transports specification?

[teor]

Hi Philipp,

> On 13 Jun 2019, at 09:41, Philipp Winter  wrote:
> 
> We are working on improving Tor's pluggable transports specification:
> 
> 
> The goal is to make the spec useful to more people and fix issues that
> have accumulated over the years.  For more context, have a look at the
> following ticket, which we use to coordinate this effort:
> 
> 
> Before changing the spec, we need to understand its shortcomings and
> what issues implementers have run into.  For those of you who have
> experience with the spec -- either Tor's version 1.0 or version 2.1
> maintained by pluggabletransports.info -- please let us know:
> 
> * What version of the PT specification and what library implementation
>  (if any) are you using?

Yawning, David, and I pointed out a bunch of issues in PT 2.0 and 2.1:

https://lists.torproject.org/pipermail/tor-dev/2017-June/012332.html

Most of these issues were present in PT 1.0, some of them were newly
introduced in 2.0.

Some of the issues were caused by tor's limited PT interface, which
we've improved recently.

Some were also caused by confusion over whether the application or the
transport should take responsibility for certain features.

I've also opened some trac tickets over the past few years. I assume
they've been triaged, and someone has an overview of which changes we
have wanted to make in the past.

> * What has your experience been with the PT specification?

I am very confused by all the different specifications and implementations.

> * How would you improve the specification?

Start by defining a scope for pluggable transports. Ruthlessly limit the
specification to a programming language-agnostic interface. Allow for
extensions to the core specification, which can be included once they are
in active use.

Document language-specific APIs separately. Or create a language-agnostic
API using some kind of binding generator. (If that results in a functional
and usable interface.)

T



signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)

[George Kadianakis]

juanjo  writes:

> Hello, this is my view of things, please be gentle as this is my first 
> proposal draft :)
>

Hello,

thanks for working on this. IMO any proof-of-work introduction proposal
can be seen as orthogonal to David's prop305 which is a rate-limiting
proposal (even tho it's not named as such) and hence deserves its own
thread.

> _ADAPTIVE POW PROPOSAL:_
>
> Client sends the INTRODUCE1 as normal.
>
> Introduction Point checks the Current Requests Rate and checks the DoS 
> settings.
>
> -DoS check is OK: send INTRODUCE2 to Hidden Service etc...
>

So far so good (even tho this is not our usual proposal format).

> -DoS settings/rate limit reached: then
>
>      1.Introduction Point generates a random 8 bytes key (IPKey) and 
> associates it with the client circuit. Then send INTRODUCE_POW to the 
> Client with the IPKey.

Is this a new cell? What's the format? Are these really keys or are they
just nonces?

IMO we should not do this through a new cell because that increases the
round-trip by one. Instead we should just embed the PoW parameters in
the onion service descriptor and clients find them there. 

>      2.Client computes POW.
>      Do{
> Generates random 8 bytes key (ClientKey).
> Generates hash(sha512/256 or sha3??) of
> hash(IPKey + ClientKey)
> } while (hash does not start with "abcde")
>

That looks like a naive PoW scheme. It would perhaps be preferable to
try to find a GPU/ASIC-resistant or memory-hard PoW scheme here, to
minimize the advantage of adversaries with GPUs etc.?  Are there any
good such schemes?

Also services should definitely be able to configure the difficulty of
the PoW, and IMO this should again happen through the descriptor.

>      3. Client sends INTRODUCE_POWR to the I.P. with the generated POW 
> and the ClientKey.

IMO this should happen as part of the INTRODUCE1 cell.

>      4. I.P. checks the POW:
>
>          -POW is correct: send INTRODUCE2 to HS.
>          -POW is not correct: send INTRODUCE_POW_ERROR to client with 
> new IPKey.
>
> *I say 8 bytes for the Keys just for example.
>
> PROS AND CONS, who needs to update Tor version?:
> --
>
> Only rate limit: Introduction Point and Hidden Service. No breakage.
>
> POW: Client, Introduction Point and Hidden Service. POW will break 
> compatibility with other v3 Hidden Services clients, if we implement a 
> way to bypass POW for old clients then this feature won't work as intended.
>
> A forgotten guy here: Authenticated Rends cell: where we make sure the 
> Client established a connection to the Rend Point before requesting the 
> INTRODUCE1.
>

Yep, that's yet another proposal (ticket #25066).
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)

[Aaron Lye]

George Kadianakis:
>>      2.Client computes POW.
>>      Do{
>> Generates random 8 bytes key (ClientKey).
>> Generates hash(sha512/256 or sha3??) of
>> hash(IPKey + ClientKey)
>> } while (hash does not start with "abcde")
>>
> 
> That looks like a naive PoW scheme. It would perhaps be preferable to
> try to find a GPU/ASIC-resistant or memory-hard PoW scheme here, to
> minimize the advantage of adversaries with GPUs etc.?  Are there any
> good such schemes?

It may be worth looking at Argon2 [1] which is designed to maximize the
cost of password cracking on ASICs based on memory-hard functions.
A different approach is the input-dependent use of several different
hash functions (cf. e.g. [2]).

[1] https://www.cryptolux.org/images/0/0d/Argon2.pdf
[2] https://www.pascalcoin.org/storage/whitepapers/RandomHash_Whitepaper.pdf

> Also services should definitely be able to configure the difficulty of
> the PoW, and IMO this should again happen through the descriptor.

yes



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension

[David Goulet]

On 12 Jun (15:39:55), George Kadianakis wrote:
> David Goulet  writes:
> 
> > 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
> >
> 
> Thanks for this proposal, it's most excellent and an essential building
> block for future work on intro point related defences.
> 
> >
> >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.
> >
> 
> Perhaps we can name it "rate-limiting parameters"? But no strong opinion.

I went more generic in order to support future "DoS" parameters which might
not be rate-limiting specific.

I personally prefer that instead of later creating a "[02] --
_PARAMETERS".

> 
> >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
> >
> 
> 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)?

Good point. Added a section about this.

Short answer: We will be using an extra 21 bytes leaving 343 bytes unused.

> 
> >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.
> >
> 
> 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.

Yes indeed! Adding discussion section!

> 
> > 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 

Re: [tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension

[David Goulet]

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
> >>   releas

Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)

[juanjo]

On 13/6/19 12:21, George Kadianakis wrote:

Is this a new cell? What's the format? Are these really keys or are they
just nonces?


Yes sorry, they are nonces.


This was only a proposal for a proposal.


Is this a new cell? What's the format? Are these really keys or are they
just nonces?

IMO we should not do this through a new cell because that increases the
round-trip by one. Instead we should just embed the PoW parameters in
the onion service descriptor and clients find them there.

Yes, this is a new cell triggered only when DoS limit is reached.

We can't embed it on the onion service descriptor because the attacker 
could precompute the PoW and make a dictionary attack. The IPKey (will 
be a nonce) should unique for each new connecting client that wants to 
send the INTRODUCE2.


What we want this way is increasing the cost of an attacker by many 
times vs only a little overhead to the I.P.



That looks like a naive PoW scheme. It would perhaps be preferable to
try to find a GPU/ASIC-resistant or memory-hard PoW scheme here, to
minimize the advantage of adversaries with GPUs etc.?  Are there any
good such schemes?

Also services should definitely be able to configure the difficulty of
the PoW, and IMO this should again happen through the descriptor.
That PoW scheme was just a simple example. We should find the right 
choice. Something hard to find but easy to check.


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev