Single Click Server Based .bit Resolution vs. Security

[phelix]

A NMControl (Namecontrol) installer that allows .bit resolution and maybe lookup of other names via a DNS/REST server, at least on Windows both without any manual configuration, is around the corner. I think it is cool to check out .bit/Namecoin but of course it is neither secure nor privacy safe. IMHO we can still offer if we are transparent about it, e.g. with a warning on install time / launch / first request. Opinions?

[biolizard89]

A NMControl (Namecontrol) installer that allows .bit resolution and maybe lookup of other names via a DNS/REST server, at least on Windows both without any manual configuration, is around the corner. I think it is cool to check out .bit/Namecoin but of course it is neither secure nor privacy safe. IMHO we can still offer if we are transparent about it, e.g. with a warning on install time / launch / first request. Opinions?

My opinion is that the primary use case of the REST feature is if a user has one computer with the blockchain, and one or more other computers that want to use the blockchain without storing it locally. For example, Android devices may not wish to store the blockchain, but still want better than SPV security. Those use cases will benefit hugely from REST. Another (smaller) use case is testing (e.g. your NMControl isn't working, so you swap in a third party's REST server and do a couple of lookups to see whether your namecoind is at fault).

Will some users do unwise things such as use some third party's REST server for production purposes? Well, probably. I don't think we should encourage it, but it's difficult to prevent someone who is determined to harm themself from doing so.

I have no problem with offering to configure for a user-supplied REST URL on install time, as long as there's a clear warning that this should be a REST server which the user fully trusts with the capability to censor, hijack, and surveil all of their Namecoin lookups.

[domob]

I'm with Jeremy here. In addition, I've been thinking again about the "Merkle tree of names" family of ideas. It needs some fleshing out of details (maybe I'll start a thread with my ideas and points for discussion soon), but apart from that, I feel motivated to finally implement a proof of concept into Namecoin Core. With that, the REST API could be made to include a "proof" of the result (optionally, in some format). That proof would, at least, consist of a Merkle branch linking the name to a block header and the block's PoW (maybe including PoW's of later blocks to further increase the strength). I. e., a query could be made without any other need to connect to the network, and you would at least know that some large computational power agreed with the result you get. Not as good as SPV (since you don't know what the longest chain is without connecting to the network), but much better than just trusting some server (as an attacker would need considerable hash power to forge the result).

When things are planned and implemented, this could readily strengthen the security of any REST consumer without too much additional changes required for the "one click install" solution.

[cassini]

Not as good as SPV

Imagine a piece of hardware (IoT) that periodically needs to obtain a few bits of information from the Namecoin blockchain. An attacker knows the physical location of the hardware and can therefore perform an attack-by-ISP as explained here.
Isn't your Merkle tree concept in this scenario much safer than SPV?

[phelix]

Not as good as SPV

Imagine a piece of hardware (IoT) that periodically needs to obtain a few bits of information from the Namecoin blockchain. An attacker knows the physical location of the hardware and can therefore perform an attack-by-ISP as explained here.
Isn't your Merkle tree concept in this scenario much safer than SPV?

Yeah this could be an advantage in some situations.

We could already do it with the current protocol but we would not know whether the value is the latest version. IMHO it would still be a good start, way better security than legacy DNS.

name_op tx, merkle tree to block header, block header, a couple of the following block headers -----> if pile of work > f(current time): value is ok. or simply display how much work went into the blocks and let the user decide: "Value is e12 hashes safe."

(note http://blog.namecoin.org/post/109811339 ... -resolvers)

[johnc]

I will assume that if you try to run all this over tor there's some issues yet;

what about vpns like hideme etc?

[biolizard89]

I will assume that if you try to run all this over tor there's some issues yet;

what about vpns like hideme etc?

The code in question does not support proxies at the moment, so to use over Tor you would need a transparent proxy or something like torsocks. VPN's would probably work out of the box.

Note, however, that neither of these would make your lookups anonymous, because your various lookups would be linkable with each other. If you're aiming for *pseudonymous* (with only one pseudonym that is linked to all lookups), you might be okay, although no guarantees.

[domob]

Note, however, that neither of these would make your lookups anonymous, because your various lookups would be linkable with each other. If you're aiming for *pseudonymous* (with only one pseudonym that is linked to all lookups), you might be okay, although no guarantees.

Why not? If you switch Tor circuits between the lookups (including a reconnect to the network) and wait some time, how would someone correlate them to each other?

Apart from that, if we use a Merkle trie, one could just query for a name prefix to mask the exact name wanted. (But I acknowledge that it may be difficult to decide about the best prefix length to query, when one has no a-priori information about the names present.)

[biolizard89]

Note, however, that neither of these would make your lookups anonymous, because your various lookups would be linkable with each other. If you're aiming for *pseudonymous* (with only one pseudonym that is linked to all lookups), you might be okay, although no guarantees.

Why not? If you switch Tor circuits between the lookups (including a reconnect to the network) and wait some time, how would someone correlate them to each other?

Apart from that, if we use a Merkle trie, one could just query for a name prefix to mask the exact name wanted. (But I acknowledge that it may be difficult to decide about the best prefix length to query, when one has no a-priori information about the names present.)

Generally speaking, end users don't manually switch Tor circuits. Tor has a feature called stream isolation, which allows different identities to automatically use different circuits. However, this is not supported by NMControl, and to my knowledge nor by Bitcoin Core. (Maybe Bitcoin Core has added it since I last looked.) That's all I meant by that -- yes, if the end user manually triggers a circuit rebuild, then the lookups will presumably be anonymous (I think).