On 11 Apr (13:45:41), George Kadianakis wrote:
George Kadianakis desnacked@riseup.net writes:
Ian Goldberg iang@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-ph...
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev