[tor-bugs] #23641 [Core Tor/Tor]: prop224: Fake client auth lines do not actually provide obfuscation

[Tor Bug Tracker & Wiki]

#23641: prop224: Fake client auth lines do not actually provide obfuscation
----------------------------+------------------------------------
 Reporter:  asn             |          Owner:  (none)
     Type:  defect          |         Status:  new
 Priority:  Medium          |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor    |        Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal          |     Resolution:
 Keywords:  prop224 tor-hs  |  Actual Points:
Parent ID:                  |         Points:
 Reviewer:                  |        Sponsor:
----------------------------+------------------------------------
Description changed by asn:

Old description:

> prop224 spec says:
> {{{
>    If client auth is disabled, fake data is placed in each of the fields
> below
>    to obfuscate whether client authorization is enabled.
> }}}
> and
> {{{
>       When client authorization is enabled, each "auth-client" line
> contains
>       the descriptor cookie encrypted to each individual client. We
> assume that
>       each authorized client possesses a pre-shared x25519 keypair which
> is
>       used to decrypt the descriptor cookie.
> }}}
>
> However, after second thinking, those fake client auth lines don't
> actually confuse the adversaries we care about:
>
> a) HSDir adversary with no onion address: This adversary does not learn
> whether client auth is enabled because of the desc padding anyway.
>
> b) HSDir adversary with onion address: This adversary can decrypt the
> first desc layer, and then attempt to decrypt the second layer with no
> client auth info. If second layer decrypts, there is no client auth. If
> decryption fails, client auth is enabled.
>
> Hence for both adversaries (a) and (b), the fact that we add fake client
> auth lines does not matter. Perhaps we could rip that feature out
> (`get_fake_auth_client_str()` etc.)
>
> The annoying thing here is that currently we actually ''require'' client
> auth lines since: `T1N(str_desc_auth_client, R3_DESC_AUTH_CLIENT, GE(3),
> NO_OBJ)`.
>
> As a first step here it might be a good idea to change the `T1N()` to
> `T0N()` and make sure that everything run ssmoothly when no client auth
> lines are provided.

New description:

 prop224 spec says:
 {{{
    If client auth is disabled, fake data is placed in each of the fields
 below
    to obfuscate whether client authorization is enabled.
 }}}
 and
 {{{
 If client authorization is disabled, the fields here can be populated with
 random
       data of the right size (that's 8 bytes for 'client-id', 16 bytes for
 'iv'
       and 16 bytes for 'encrypted-cookie' all encoded with base64).
 }}}

 However, after second thinking, those fake client auth lines don't
 actually confuse the adversaries we care about:

 a) HSDir adversary with no onion address: This adversary does not learn
 whether client auth is enabled because of the desc padding anyway.

 b) HSDir adversary with onion address: This adversary can decrypt the
 first desc layer, and then attempt to decrypt the second layer with no
 client auth info. If second layer decrypts, there is no client auth. If
 decryption fails, client auth is enabled.

 Hence for both adversaries (a) and (b), the fact that we add fake client
 auth lines does not matter. Perhaps we could rip that feature out
 (`get_fake_auth_client_str()` etc.)

 The annoying thing here is that currently we actually ''require'' client
 auth lines since: `T1N(str_desc_auth_client, R3_DESC_AUTH_CLIENT, GE(3),
 NO_OBJ)`.

 As a first step here it might be a good idea to change the `T1N()` to
 `T0N()` and make sure that everything run ssmoothly when no client auth
 lines are provided.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23641#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online