[tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Taylor R Campbell]

> Date: Sun, 26 Mar 2017 14:24:41 +0200
> From: Alec Muffett <alec.muffett at 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.