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).
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!