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

[George Kadianakis]

Michael Rogers <michael at 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!