[tor-dev] Action items wrt prop224 onion address encoding (was Re: Proposition: Applying an AONT to Prop224 addresses?)

[George Kadianakis]

Ian Goldberg <iang at cs.uwaterloo.ca> writes:

> On Wed, Apr 05, 2017 at 10:02:07AM -0400, David Goulet wrote:
>> Another thing about this I just thought of. This AONT construction seems wise
>> to use. But it's still not entirely clear to me why we need a 1bit version
>> field. Taking this:
>> 
>>     base64( AONT( pubkey || 0x0000 ) || version)
>> 
>> If the version is 1 byte, then only the end of the address can be mangled with
>> and if it is, the tor client won't be able to fetch the descriptor because of
>> how the URL is constructed (correct version number is needed).
>> 
>> So I really don't see the phishing attack here being successful at all...?
>> 
>> Can you enlighten what attack we are trying to avoid here that we require a
>> 1bit version field?
>
> I believe the danger Alec was wanting to avoid was that someone (not the
> onion service owner) could take an existing onion address, bump the
> version number (which wouldn't change the vanity beginning of the
> address), and upload the very same descriptor to the resulting blinded
> address (under the new version number).  Then the modified address would
> work just like the original.
>
> As mentioned elsewhere in the thread, this is solved if that descriptor
> contains (under the signature by the "master" onion key) the actual
> onion address you were expected to use to get there.  Does it?  If so,
> I think we don't have to worry about this problem at all.
>

Hello people,

the AONT thread has grown to an immense size and includes all sorts of
discussions, so I will split it into two smaller threads with just
action items so that we move this forward ASAP (as this interacts with
our current implementation efforts).

>From skimming the thread, this seems like the general discussion flow:

- "Let's do AONT so that no one can tweak the onion address while
  keeping the same blinded pubkey so that people can't create multiple
  onion addresses that point to the same key and look almost the same"

- "Hm, but there are no bits to tweak apart from the version field"

- "But maybe v4->v3 downgrade attacks are possible using the version
  field, so let's include the whole onionaddress (including version)
  into the blinded key derivation"

- But then maybe in 2020 an attacker is able to replay a v4 descriptor
  into an HSDir as a v3 descriptor, and then do a downgrade attack by
  persuading a victim to fetch the v3 descriptor (see Ian/Alec latest mails)

And I think then we ended up with:

"Then let's include the canonical onionaddress (including version) into
the descriptor so that clients can verify that they used the
onionaddress that the onionservice was intending for them to use"

So I guess the current suggested plan is to add an extra descriptor
field with the onionaddress (or its hash) into the _encrypted parts_ of
the descriptor so that clients can do this extra verification to defend
against downgrade attacks.

I think this seems like a reasonable defence here, and more safe +
engineering-friendly than the AONT stuff (see David's email). We should
just make sure that this plan does not interact badly with things like
onionbalance and future name systems.

Do you think this makes sense?  If yes, I will write a spec patch in the
next few days.

And I think this sums up the discussion wrt onion address encoding. I'm
going to start a new thread about the ed25519-related suggestions that
were thrown into this thread.

Cheers!