Michael Rogers michael@briarproject.org writes:
On 11/04/17 11:45, George Kadianakis wrote:
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.
Is the version number also included in the blinded key derivation? I haven't been keeping up with prop224 developments, so apologies if that's already been settled, but in your previous email it sounded like it was one of the suggestions but not one of the action items.
That's a fine question, and it made me think deeper about our options.
I think both of the following suggestions from my previous email aim to protect from the same attacks: a) Include version number in blinded key derivation formula b) Include canonical onion address in descriptor
Both (a) and (b) above aim to protect against scenarios where an attacker (without private keys) takes a legitimate onion address, tweaks its metadata bits (version/whatever), and creates a different-but-equivalent onion address that has the exact same behavior as the original one (points to the same 25519 key, same descriptor, etc.). See Alec's and Ian's emails for a demonstration of how this can be exploited: https://lists.torproject.org/pipermail/tor-dev/2017-April/012160.html https://lists.torproject.org/pipermail/tor-dev/2017-April/012159.html
I'm pretty sure that both (a) and (b) defend against Alec's and Ian's attack since:
- With (a), the different-but-equivalent onion address would produce a different blinded key from the original onion address. The attacker would not be able to forge a signature for the descriptor since they don't know the private part of the new blinded key, so the descriptor would not be accepted by the HSDir or the client.
- With (b), the different-but-equivalent onion address would work, but when the client fetches the descriptor, the client would verify the new "canonical-onion-addr" field, notice that they reached this onion service from another address, and reject the descriptor. It's like we are including an SSL CN field in our HS descriptors.
I considered (b) easier to understand and reason about, and it also seems to protect against a wider variety of descriptor replay attacks, and that's why I suggested we go with (b).
My main fear with (b) is that in the future we might come up with a new load-balancing scheme of sorts that would get screwed by the "canonical-onion-addr" field. It does not seem to pose a problem with onionbalance or stealth-auth kind of schemes, so all is good so far. Please let me know if you can think of a scenario where (b) is a bad idea.
If the version number is included in the descriptor but not in the blinded key derivation, can a service publish descriptors for multiple protocol versions? Would there be a conflict if the HS directories store the descriptors under the same blinded key?
Yes it's possible to publish descs for multiple protocol versions, since we use a different URL for each version. Quoting from spec:
Hidden service descriptors conforming to this specification are uploaded with an HTTP POST request to the URL /tor/hs/<version>/publish relative to the hidden service directory's root, and downloaded with an HTTP GET request for the URL /tor/hs/<version>/<z> where <z> is a base64 encoding of the hidden service's blinded public key and <version> is the protocol version which is "3" in this case.
Also the HSDirs store the descriptors using both the publickey and the version as indices, so this should not be a problem.
---
Thanks for all the feedback people.
Greetings from Athens!