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

[George Kadianakis]

Ian Goldberg <iang at cs.uwaterloo.ca> writes:

> On Mon, Apr 03, 2017 at 02:53:17PM +0100, Alec Muffett wrote:
>> On 3 April 2017 at 13:04, George Kadianakis <desnacked at riseup.net> wrote:
>> 
>> > I'm calling it weird because I'm not sure how an
>> > attacker can profit from being able to provide two addresses that
>> > correspond to the same key, but I can probably come up with a few
>> > scenarios if I think about it.
>> 
>> 
>> Hi George!
>> 
>> I'll agree it's a weird edge case :-)
>> 
>> I think the reason my spider-sense is tingling is because years of cleaning
>> up after intrusions has taught me that sysadmins and human beings are very
>> bad at non-canonical address formats, especially where they combine them
>> with either blacklisting, or else case-statements-with-default-conditions.
>> 
>> If one creates scope for saying "the address is <foo>.onion but you can
>> actually use <foo'>.onion or <foo''>.onion which are equivalent" - then
>> someone will somehow leverage that either a) for hackery, or b) for social
>> engineering.
>> 
>> Compare:
>> 
>> * http://017700000001
>> * http://2130706433
>> * http://0177.0.0.1  <- this one tends to surprise people
>> * http://127.0.0.1
>> 
>> …and the sort of fun shenanigans that can be done with those "equivalent
>> forms"
>> 
>> People who've been trained not to type [X] into their browser, might be
>> convinced to type [X']
>> 
>> It's a lot easier for people to cope with there being one-and-only-one
>> viable form for any given hostname or address-representation.
>
> But as I said to Alec in AMS, anyone on the internet can register
> "facebook.mydomain.com" and have the A record point to the same thing as
> facebook.com.  So there are always alternate names for any given
> website.  TLS, of course, is designed to protect against these
> shenanigans.
>

Hey,

sorry for the slow responses to this thread. Got lots of post-meeting
backlog to handle, and I'm also working on the various ed25519 stuff.

Specifically, I'm now working on the suggested check of multiplying any
received curve25519 point with the group order and ensuring the result
is the identity element.

> Prop224 *also* (mostly) protects against these shenanigans, because even
> if there were two onion addresses that resolved to the same pubkey, the
> daily blinded version incorporates the original onion address (not just
> the pubkey, right?  *Right?*), so the alternate address-with-same-pubkey
> won't actually point anywhere.  However, an adversary can upload a
> descriptor there; I'm not sure what the implications of that are just
> now.
>

Actually, I *don't* think that the blind factor of the derived key
incorporates the actual onion address. Citing the proposal:

  Let the basepoint be written as B. Assume B has prime order l, so
  lB=0. Let a master keypair be written as (a,A), where a is the private
  key and A is the public key (A=aB)

  To derive the key for a nonce N and an optional secret s, compute the
  blinding factor h as H(A | s, B, N), and let:

Perhaps we can add another component to h as follows:
         h = H(A, s, B, N, ONIONADDRESS)
where ONIONADDRESS is a string representation of the service's onion address.

I think this code is already implemented, but this might be worth fixing anyhow.
I'll make a ticket.

> The other thing to remember is that didn't we already say that
>
> facebookgbiyeqv3ebtjnlntwyvjoa2n7rvpnnaryd4a.onion
>
> and
>
> face-book-gbiy-eqv3-ebtj-nlnt-wyvj-oa2n-7rvp-nnar-yd4a.onion
>
> will mean the same thing?  So we're already past the "one (st)ring to
> rule them all" point?
>

I don't think we have actually decided on such a feature yet. It was
suggested but the tradeoffs are not clearly skewed to the "let's do it"
direction.

Cheers!