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

[David Goulet]

On 11 Apr (13:45:41), George Kadianakis wrote:
> George Kadianakis <desnacked at riseup.net> writes:
> 
> > 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).
> >
> > <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.

Yeah I was puzzled about the optional idea but agree that being able to
rollback without having client freak out could be a good idea.

Also, if we ever come up with stealth client authorization one day, that field
could be affected in some ways... unsure but still, worth being more safe than
very sorry and stuck with that field :).

Last comment. Can we maybe add a sentence somewhere that explains what the
client should do with this field? I assume it is has simple as doing a
strcmp() with the original address you requested the descriptor but still.

Thanks!
David

> 
> Please let me know if you think this behavior is worthwhile merging upstream and implementing.
> 
> Thanks! :)
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-- 
8HiR+n98Vq26HSn5XkNn84QMAdPZOrIJ8HM4ZCUadzk=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170411/c318e606/attachment.sig>