<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hello, this is my view of things, please be gentle as this is my
first proposal draft :)</p>
<p><u>ADAPTIVE POW PROPOSAL:</u><br>
<br>
Client sends the INTRODUCE1 as normal.<br>
<br>
Introduction Point checks the Current Requests Rate and checks the
DoS settings.<br>
<br>
-DoS check is OK: send INTRODUCE2 to Hidden Service etc...<br>
<br>
-DoS settings/rate limit reached: then<br>
<br>
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.<br>
2.Client computes POW.<br>
Do{<br>
Generates random 8 bytes key (ClientKey).<br>
Generates hash(sha512/256 or sha3??) of<br>
hash(IPKey + ClientKey)<br>
} while (hash does not start with "abcde")<br>
<br>
3. Client sends INTRODUCE_POWR to the I.P. with the generated
POW and the ClientKey.<br>
4. I.P. checks the POW:<br>
<br>
-POW is correct: send INTRODUCE2 to HS.<br>
-POW is not correct: send INTRODUCE_POW_ERROR to client
with new IPKey.<br>
<br>
*I say 8 bytes for the Keys just for example.<br>
<br>
PROS AND CONS, who needs to update Tor version?:<br>
--------------<br>
<br>
Only rate limit: Introduction Point and Hidden Service. No
breakage.<br>
<br>
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.<br>
<br>
A forgotten guy here: Authenticated Rends cell: where we make sure
the Client established a connection to the Rend Point before
requesting the INTRODUCE1.<br>
<br>
</p>
<div class="moz-cite-prefix">On 12/6/19 14:39, George Kadianakis
wrote:<br>
</div>
<blockquote type="cite" cite="mid:87zhmn0yg4.fsf@riseup.net">
<pre class="moz-quote-pre" wrap="">David Goulet <a class="moz-txt-link-rfc2396E" href="mailto:dgoulet@torproject.org"><dgoulet@torproject.org></a> writes:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Thanks for this proposal, it's most excellent and an essential building
block for future work on intro point related defences.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Perhaps we can name it "rate-limiting parameters"? But no strong opinion.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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)?
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 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] <a class="moz-txt-link-freetext" href="https://lists.torproject.org/pipermail/tor-dev/2019-May/013837.html">https://lists.torproject.org/pipermail/tor-dev/2019-May/013837.html</a>
[2] <a class="moz-txt-link-freetext" href="https://trac.torproject.org/15516">https://trac.torproject.org/15516</a>
_______________________________________________
tor-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">_______________________________________________
tor-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a>
</pre>
</blockquote>
</body>
</html>