Date: Sun, 26 Mar 2017 14:24:41 +0200 From: Alec Muffett alec.muffett@gmail.com
This is a point of significant concern because of issues like phishing and passing-off - by analogy: t0rpr0ject.0rg versus torproject.org - and other games that can be played with a prop224 address now, or in future, to game user experience. [...] The result would be onion addresses which are less "tamperable" / more deterministic, that closer to one-and-only-one published onion address will correspond to an onion endpoint.
What does the panel think?
What is the threat model an AONT defends against here, and what security properties do we aim to provide against that threat?
Here are a few candidates. Suppose I own 0123456789deadbeef2.onion, where 2 is the onion version number.
T1. Adversary does not know 0123456789deadbeef2.onion but controls all onion service directories. (SP1) Adversary can't discover 0123456789deadbeef2.onion or thereby distinguish descriptors for 0123456789deadbeef2.onion from other descriptors simply by controlling what is in the directories. -> With or without AONT, since the onion service descriptors are encrypted, the adversary can't learn their content anyway.
T2. Adversary knows 0123456789deadbeef2.onion and controls all Tor nodes except for the onion service server and client. (SP2) Adversary cannot impersonate 0123456789deadbeef2.onion. -> With or without AONT, adversary can't make onion descriptor signatures that are verified by the 0123456789deadbeef2.onion key unless they have broken Ed25519. (SP3) Adversary cannot impersonate 0123456789deadbeefN.onion for any N *other* than 2. -> With or without AONT, if the signature on the onion descriptor always covers the complete .onion address, including the version number, the adversary can't do this without also being able to forge signatures for 0123456789deadbeef2.onion anyway and thus break Ed25519. (SP4) Adversary cannot DoS 0123456789deadbeef2.onion. -> With or without AONT, if adversary knows legitimate .onion address key, they can already remove any onion descriptors with signatures verified by the .onion address key, even if the signatures are decrypted. So we can't provide this security property anyway as long as the adversary knows the legitimate .onion address.
T3. Adversary (a) knows 0123456789deadbeef2.onion, (b) can spend compute to find a private key whose public key has some chosen bits, and (c) can submit descriptors to onion directories. (SP5) Adversary cannot match all except replacement of l by 1, o by 0, &c. -> With or without AONT, this confusion is already excluded by base32 encoding. (SP6) Adversary cannot match all except long enough suffix. -> Finding priv to fix prefix of Ed25519_priv2pub(priv) || cksum is almost surely just as hard as finding priv to fix prefix of AONT(Ed25519_priv2pub(priv) || cksum || version) or any other arrangement of cksum and version.
(This assumes the AONT has low AT cost to evaluate -- but if you choose an AONT with high AT cost, that will severely penalize legitimate users of onion services, and also limit vanity onions to major corporations like Facebook and Google.)
So what security properties does an AONT give against what threat models? I'm probably missing something obvious here, but I expect it will be helpful to articulate exactly what function it serves, for future readers.