[tor-dev] Onioncat and Prop224

[Jeremy Rand]

grarpamp:
> Hi Jeremy.

Hey grarpamp,

Sorry for the delayed reply.

> In regard your post 'Tor and Namecoin' here...
> https://lists.torproject.org/pipermail/tor-dev/2016-July/011245.html
> 
> In this thread prefixed 'Onioncat and Prop224' started and
> spanning from here through now...
> https://lists.torproject.org/pipermail/tor-dev/2016-April/010847.html

Thanks for the pointer.  For some reason I wasn't aware of that thread,
even though those messages did hit my inbox.  Probably because in April
2016 I was busy finishing semester projects and wasn't spending much
time reading email.

> Onioncat is interested in finding way to extend IPv6 addressing
> past prop224 for use by IPv6 native user applications.
> 
> There are some purely internal ideas for that. Yet to extent
> an internal tor+onioncat solution may be difficult,
> onioncat may need to develop or shell out to a non-native
> mapping and lookup layer. Namecoin has been mentioned
> among prebuilt potential solutions.

Hmm, this is indeed an interesting use case.

> Note clearly namecoin usage here *not* for human DNS style
> naming such as myeasyname.onion. But as a mapping between
> crypto key of onion (descriptor, hsdir, etc) and character string
> of (in format of) IPv6 address for use in IP / tunnel addressing.

Okay, so I've been pondering this for a little while.  There are going
to be some challenges in doing this properly, but I *think* that most or
all of the challenges are solvable with some effort.  Full disclosure: I
will need to check with the other Namecoin devs to see if I might have
missed anything, so I might need to issue corrections to these comments
if I did miss anything important.

Most of the challenges of dealing with this use case are going to be
because Namecoin simultaneously aims to satisfy 2 goals:

1. Enforce that names are unique and only updatable by the owner.
2. Enforce that names are scarce, nonfungible, and resistant to squatting.

Both of these goals are relevant for a DNS-like system that maps
human-meaningful names to values.  The first goal is relevant to
Onioncat-like systems, but the second goal seems to be inapplicable,
because (I presume) most end users don't care what IPv6 address Onioncat
assigns them, and if a particular IPv6 address happens to be unavailable
for registration, picking a different one isn't going to annoy anyone.
(If, for some reason, there are Onioncat use cases that make this
statement incorrect, please let me know.)

Some of the challenges that are posed by the existence of goal 2 include:

Creating a new IPv6 address would cost some money, conceptually similar
to registering a domain name.  This might incentivise unsafe user
behavior such as reusing identities.  There have been similar concerns
raised in the past about other use cases of Namecoin (including some
features of domain names) where name scarcity unintentionally
incentivises insecure user behavior, so I'm guessing that we're open to
the possibility of adjusting the system to solve this.

Creating a new IPv6 address is subject to a 12-block (around 2 hours)
waiting period (a salted commitment to the name is placed in the
blockchain, and 2 hours later the name and salt are revealed), so that a
newly created name cannot be sniped by someone relaying the transaction
or during a small chain reorganization.  I'm guessing that some Onioncat
users may not want to have to wait 2 hours for their new IPv6 address to
start working.  This also might incentivise reuse of identities (see
previous challenge).

Okay, so here is a suggestion on how this might be fixable.

Let's say that we create a new class of names in Namecoin.  This might
be a different set of name opcodes that have modified semantics.  In
this email I'll refer to this new class of names as MR
(machine-readable) names, and the existing names as HR (human-readable)
names.

MR names have the following new properties:

1. MR names are not subject to name registration fees.  (A fee is paid
to the miner just as would be done for a currency transaction.)
2. MR name registrations are not subject to a 12-block waiting period.
3. MR name registrations must be signed by a public key whose hash is
equal to the name being registered.
4. MR names are considered to be in a separate set from HR names for the
purpose of name uniqueness checks, i.e. registering a domain name as an
MR name is valid even if the domain name already exists, but software
that looks up the domain name will receive the HR name unless it
requests the MR name.

I think MR names would solve both of the challenges I listed, without
compromising goal 1.  Sniping is prevented because a sniper would need
to possess a private key whose public key hash is the name being sniped.
 In the case of Onioncat, the public key would be the .onion public key.

Unfortunately, this construction introduces a new issue: there are a lot
of public key systems and hash functions, and different applications
will want different choices.  If this is used to prevent sniping, then
it would have to be part of blockchain validation, which makes
supporting arbitrary pubkey systems and hash functions impossible.

So, we can instead modify this construction a bit, as follows:

5. MR name uniqueness is not part of transaction/block validation.
6. The signatures used in property 3 are not used for transaction/block
validation.
7. When an MR name is looked up, the Namecoin client returns all of the
matching unspent transactions (meaning that since MR names are not
unique, there may be multiple unspent transactions that match the name).
8. MR name lookups also return the signatures used in property 3, for
each matching transaction.
9. MR name lookups also return the registration block height of each
matching transaction.
10. The application layer that requests a name lookup (e.g. Onioncat) is
responsible for choosing the earliest-registered name whose signature
used in property 3 is valid according to whatever signature validation
rules the application layer uses.

The only attack I see here is that it's possible to spam invalid
signatures into the blockchain and make everyone else carry them around.
 Transaction fees and block size limits should (I think) prevent this
from being a problem, just as with Bitcoin.

This kind of modification would, I think, be a softfork.  It would be a
fairly significant undertaking, but I think it would be useful for a lot
of other use cases besides Onioncat.

Again, I haven't discussed this outline with the other Namecoin devs, so
maybe there are problems that I'm not seeing.

> And most certainly any external layer must be capable of having
> nodes binding natively in the Tor / I2P / etc networks, and
> preferably being strictly private entirely within them (like how
> private Tor / I2P / Bitcoin nets can be deployed by generating
> new authorities, keys, genesis, etc). Outproxy is not an option.

Bitcoin and Namecoin nodes can be exposed as Tor hidden services (I
believe there's even code in there now for automatically configuring
such a hidden service via the Tor control port).  I don't think there's
any built-in support for I2P (unless something was added since I last
looked), but if I2P can expose a local TCP service as an I2P service,
and if I2P allows such TCP services to be connected to by exposing a
SOCKS interface, I'm guessing that it should mostly work (famous last
words).  The only thing that would break that way is peer exchange:
Bitcoin and Namecoin nodes normally share peer addresses, and although
this works just fine with Tor hidden services, I don't think it would
work out of the box with I2P (unless someone's added that since I last
looked).

Although it is possible to deploy private Bitcoin and Namecoin networks
(I did it at a workshop I gave at DWS so that I could mine blocks on
demand), usually people do this for testing or demonstration purposes,
not for real-world applications.  The reason is that blockchains'
security assumptions include the assumption that they have a reasonably
high hashrate from a reasonably diverse set of miners.  An
Onioncat-specific Namecoin network would probably have a very low
hashrate compared to the main Namecoin network, which means that it
would be much easier to perform a 51% attack.  Merged mining could,
hypothetically, raise the hashrate, except that to do merged mining, the
miners would have to be connected to the public Bitcoin network.  In
addition, it's usually very unprofitable to mine Bitcoin or Namecoin
over Tor or I2P, because the additional latency causes much higher
orphan rates.  (Most Bitcoin and Namecoin miners spend considerable
effort obtaining low-latency connections for relaying blocks to and from
other miners.)

Might I ask what the motivation is for having a completely separate
Namecoin network inside Tor/I2P, that can't be satisfied by binding
participants' nodes to Tor/I2P hidden services while allowing some users
who don't want or need anonymity to relay transactions and blocks
between clearnet and Tor/I2P?

> It's also not ideal to be expending resources on mining
> whereas other form of simpler distributed registry network
> may suffice onioncat purpose.

Might I ask what alternatives to mining would suit Onioncat's needs?  I
admit that I'm not incredibly familiar with Onioncat's needs and threat
model, so if there's something simpler that works well, I'm unaware of
what it would be.

> Anyhow, fyi as to this thread and any ideas / collab :)

Yes, thank you for bringing this up.  Feel free to give feedback on the
above, suggest alternative methods, etc.  I'm not certain whether
Namecoin is the best solution for Onioncat's needs (and it sounds like
no one is certain at this point), but I'm happy to do what I can to
flesh out the ideas so that we can figure out if it's the right
solution, and if so, exactly what that solution would look like.

Cheers,
-Jeremy

PS: I'm not subscribed to the other lists; if you are subscribed to them
and think they'd like to see this reply, feel free to forward it to them.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160807/1d81f968/attachment.sig>