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

[Alec Muffett]

On 5 April 2017 at 15:11, Ian Goldberg <iang at cs.uwaterloo.ca> wrote:

> I believe the danger Alec was wanting to avoid was that someone (not the
> onion service owner) could take an existing onion address, bump the
> version number (which wouldn't change the vanity beginning of the
> address), and upload the very same descriptor to the resulting blinded
> address (under the new version number).  Then the modified address would
> work just like the original.
>


In a nutshell, yes.

I've been having a discussion with Taylor Campbell off-list, and I wrote:

   - *… let me try something on you: *
   -
*The year is 2019.  *
   -
*What would _you_ do  *
   -
*in order to surface to the user  *
   -
*that the onion address in front of them,  *
   -
*one with a given public key which they've previously used and trusted
   before *
   -
*such that the leftmost 32 bytes, base32 encoded, are familiar to them,  *
   -
*is actually a downgraded version-2 format of address *
   -
*against which a bug is being exploited by (say) the FBI *
   -
*rather than the more secure version-3 form which they were expecting and
   had previously used, *
   -
*when all of the information pertinent to versions and checksums is at the
   right-hand-end of the encoded address? *
   - *This is basically where I am coming from.*
   -
*My thinking: Make it brittle. Mix the version (etc) into the represented
   form so that if one messes with a single bit, one perceptibly impacts the
   entire string representation of the onion address. How would you attack
   this? *


...and also:


> *do we want to be teaching users that:*
> *--- eh2tndsmiher4dqv266z5ii2xkt6brx2llwliq3jim233e5c5bc5, and*
> *--- eh2tndsmiher4dqv266z5ii2xkt6brx2llwliq3jim233e5d5bc5**...are
> actually the same thing, but if and only if they differ in the N-5'th
> character?*



...and:


> *… up front I'll just say that my perspective of this class of threat
> comes from observations like *
> *a) people are creative, and if you give them malleability they will use
> it to create onion addresses including embedded "poop-emoji" and the like.*
> *b) people generalise, so that having learned that $SOME_CHARACTER in an
> onion address is malleable, they will assume that most/all of them are and
> subsequently fall for phishing attacks.**c) people are, as a group, given
> the entire Tor prop224 ecosystem, infinitely more creative than I can be at
> finding ways to exploit it, therefore it makes sense to screw down the
> crypto to present as small an attack surface as possible.*



...and:


> *An old programmer maxim is that one should provide for Zero, One, or an
> Infinite number of any resource.  *
> *Since we do not desire an infinite number of representations of an onion
> address (per Roger) - and zero would not be useful, we should shoot for
> one, and only one.**Not a cryptographic argument, but I think it's a
> human one.  :-)*


There's a lot more, but I don't want to bury folk with a huge multi-message
e-mail exchange; plus there is a lot of useful context "up-thread".  :-)



> As mentioned elsewhere in the thread, this is solved if that descriptor
> contains (under the signature by the "master" onion key) the actual
> onion address you were expected to use to get there.  Does it?  If so,
> I think we don't have to worry about this problem at all.


I hope it does.  That sounds very much like what I expect to see in other
network stacks.  :-)

    -a

-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170405/105fc40c/attachment-0001.html>