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

[George Kadianakis <desnacked@xxxxxxxxxx>]

George Kadianakis <desnacked@xxxxxxxxxx> writes:

> Ian Goldberg <iang@xxxxxxxxxxxxxxx> 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).
>
> <snip>
>
> "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.
>

And here is a torspec branch that specifies this behavior:
     https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224-desc-phishing

We basically add the canonical onion address in the inner encrypted
layer of the descriptor, and expect the client to verify it. I made this
feature optional in case we ever decide it was a bad idea.

Please let me know if you think this behavior is worthwhile merging upstream and implementing.

Thanks! :)
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev