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

[David Goulet]

-------------- next part --------------
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190612/06a972e3/attachment.sig>