Hello Tor devs, Namecoin is interested in collaboration with Tor in relation to human-readable .onion names; I'm reaching out to see how open the Tor community would be to this, and to get feedback on how exactly the integration might work. The new hidden service spec is going to substantially increase the length of .onion names, which presents usability concerns. Namecoin provides a way to resolve a human-readable .bit name to a .onion name. Another benefit of Namecoin is that it provides a way to lookup TLS fingerprints for clearnet .bit sites, which reduces the risk of MITM attacks on clearnet websites from malicious or compromised CA's. I had the pleasure of meeting Mike Perry at the Decentralized Web Summit at the Internet Archive in June; I talked to him about Namecoin's rough plans and he suggested I post here. I understand that Riccardo Spagni from Monero discussed this topic as well with Roger Dingledine at the Security in Times of Surveillance conference at Ei_PSI. The two most major concerns that I expect would be brought up involve anonymity and blockchain size. Here's how we plan to deal with these issues: Namecoin already provides location-anonymity for name registrations assuming that it's routed via Tor. It's also necessary to broadcast transactions for different names to different peers, which isn't coded yet, but this is just coding work rather than an engineering challenge -- a usable workaround today is running multiple Namecoin wallets. The more interesting challenge is blockchain anonymity for registrations, due to the linkability required for blockchain validation. An important point here is that transactions for a given name are inherently linkable to each other, and that this isn't problematic. The problem would come when multiple names are linked together, or when a name is linked with currency transactions. The solution I've come up with is to use atomic cross-chain trades, which let a user buy namecoins using a cryptocurrency that is designed to provide anonymity (such as Monero or Zcash, both of which have cryptographic proofs of anonymity, given a certain anonymity set and security assumptions). The user would use an anonymous cryptocurrency to buy a small amount of namecoins (enough to register a single name and keep it renewed for a while). If the user wanted to register another name, she would perform another atomic cross-chain trade, receiving namecoins that are not linked to the namecoins obtained for the first name. As long as those namecoins are not mixed by the wallet software, the names remain unlinked. Many users won't want to download the full Namecoin blockchain (around 3 GB at the moment). I have a proof-of-concept SPV-based Namecoin name lookup client working as of early June. I just got a large part of that code upstreamed into libdohj, and I'm working on getting the rest upstreamed and released. It's in Java (based on BitcoinJ), so it's not subject to the memory safety concerns that C/C++ code are. The SPV name lookups are implemented in 3 ways, depending on the user's needs: Option A: 1. Block headers are synced over the Namecoin P2P network. (Over clearnet this takes about 5 minutes the first time it runs.) 2. An index mapping unexpired block heights to block hashes is constructed, so that lookups can be done quickly. (This occurs when the SPV client starts, after syncup has completed; it's fast enough that I haven't found a need to benchmark it.) 3. When a name lookup request is received, the client asks a remote API server for the height of the last update of the name. 4. The client looks up the block hash of that height from its index, and requests that block over the P2P network. 5. The client verifies that the received block matches the correct hash and that the block follows Namecoin rules (e.g. verifying the merkle root). 6. The client looks through the transactions in the block until it finds the one that updates the name. 7. The client retrieves the value of the name from that transaction, and returns it to the user. Option B: 1 through 3. Same as Option A. 4. The API server also provides the full content of the transaction, as well as a merkle proof of inclusion in the block. 5. The client verifies that the merkle proof links the hash of the provided transaction to the merkle root of the block header with the given height. 6. The client retrieves the value of the name from the provided transaction, and returns it to the user. Option C: 1. Block headers are synced over the Namecoin P2P network, as well as full blocks for the past year (meaning that all full blocks that contain unexpired name data will be synced). (Over clearnet this takes about 10 minutes the first time it runs.) 2. An index mapping names to transactions is constructed as the full blocks are downloaded. (This uses LevelDB.) 3. When a name lookup request is received, the client looks up the transaction in the LevelDB index. 4. The client retrieves the value of the name from that transaction, and returns it to the user. For Options A and B, if the API server is malicious, it can do any of the following: 1. Falsely claim that the name doesn't exist. 2. Provide outdated name data that is less than 36000 blocks old (the expiration period for Namecoin). (Option C is not vulnerable to either of those attacks.) If multiple API servers are consulted, and they return different results, it is easy to tell which is lying (although I haven't implemented any such logic yet). The API server cannot do any of the following: 1. Provide name data that isn't from the blockchain with the most work. 2. Provide name data that is more than 36000 blocks old (the expiration period for Namecoin). The reason an API server is used in Options A and B instead of the P2P network, is that the P2P network is unauthenticated and easy to Sybil. The P2P network is great for getting data that is independently verifiable (e.g. block headers and contents of blocks), but it's unwise to rely on the P2P network to get unverifiable data such as a block height of a name. An API server is authenticated (currently via CA-based TLS, but a cert pin or PGP signing is certainly doable), which reduces the possible points of attack. This is analogous to why Tor uses centralized directory authorities -- authenticated trust points are harder to Sybil. (We do have longer term plans to introduce a way for SPV clients to get the latest transaction associated with a name, without using an API server or needing to download any full blocks, but that's out of scope of this email.) Options A and B do reveal to the API server which name is being looked up. If mode A is used, it also reveals to a P2P peer which block height is being looked up (which narrows the set of names by a factor of ~36000). Therefore, Tor stream isolation should be used in such cases. (That's not implemented yet.) Option C doesn't generate any network traffic on lookups, so it doesn't reveal anything. In my testing, an SPV-based name lookup using Option A takes around 650 milliseconds (over clearnet). The vast majority of this is latency to the API server (the server I'm testing with is on a low-budget hosting plan). The portion consisting of a block retrieval over P2P takes around 98 milliseconds (although it varies by block size). Option C takes around 4 milliseconds. The storage overhead of Option C's LevelDB database is around 400 MB right now, although I believe it's feasible to reduce this significantly. There are a few options I can think of for integrating this with Tor for .onion naming. One would be to modify OnioNS to call the Namecoin SPV client. This would concern me because OnioNS is in C++, which introduces the risk of memory safety vulnerabilities. Another would be to use an intermediate proxy like Yawning's or-ctl-filter. A third option would be to try to get external name resolution implemented in Tor itself, which I believe Jeff Burdges has suggested in the past. If Option A or B is used, any solution would need to pass the stream isolation info to the SPV client. Integrating this with Tor Browser for TLS certificate validation might involve a Firefox patch. There are tricks that can be done with the CertDB and SiteSecurityService XPCOM interfaces that will do the job without Firefox patches, but XPCOM is being phased out by Mozilla in favor of WebExtensions, and I'm unaware of any equivalent features in WebExtensions. (Also, it's unclear to me whether CertDB and SiteSecurityService would introduce isolation issues -- I can't think of any obvious attacks, but I haven't thought very hard about it.) I'm trying to engage with Mozilla to see if we can work out a WebExtensions feature for this, but nothing conclusive has happened on that front yet. On the subject of reproducible builds, I've never tried to build Java code in Gitian, so I'm not certain how difficult it's going to be. Since Android uses Java, maybe the Guardian Project devs would have some insight into the best way to do it. One of the Namecoin developers (Joseph Bisch) is really good with reproducible builds (you probably know him since he's the author of the Debian guest support in Gitian), so I'm reasonably confident that a way to do it can be found. I'd love to hear feedback on all of this. Cheers, -Jeremy Rand Lead Application Engineer of Namecoin
Jeremy Rand <jeremyrand@airmail.cc> writes:
[ text/plain ] Hello Tor devs,
Namecoin is interested in collaboration with Tor in relation to human-readable .onion names; I'm reaching out to see how open the Tor community would be to this, and to get feedback on how exactly the integration might work.
The new hidden service spec is going to substantially increase the length of .onion names, which presents usability concerns. Namecoin provides a way to resolve a human-readable .bit name to a .onion name. Another benefit of Namecoin is that it provides a way to lookup TLS fingerprints for clearnet .bit sites, which reduces the risk of MITM attacks on clearnet websites from malicious or compromised CA's.
<snip>
There are a few options I can think of for integrating this with Tor for .onion naming. One would be to modify OnioNS to call the Namecoin SPV client. This would concern me because OnioNS is in C++, which introduces the risk of memory safety vulnerabilities. Another would be to use an intermediate proxy like Yawning's or-ctl-filter. A third option would be to try to get external name resolution implemented in Tor itself, which I believe Jeff Burdges has suggested in the past. If Option A or B is used, any solution would need to pass the stream isolation info to the SPV client.
Hello Jeremy, I'm a big noob when it comes to blockchains, namecoin, SPV clients and such, so I'm mainly going to focus on how to integrate this with Tor. It seems to me that a plausible way to kickstart this big project would be to make an unofficial add-on for TBB that can do the namecoin dance. People can then install it and experiment with it. If it fits the Tor use case well, then a community might be formed that will push this project forward even more. If it's an optional add-on, we also don't have to worry that much about the 400MB blockchain size, since it's gonna be optional and only people who want it will have to download it. This way we can learn how much of a problem the download size is anyway (it seems to me like a total blocker for people in non-western fast-internet countries). That's why I would suggest experimenting with the first two approaches you mentioned that don't require a modification to Tor's protocol. Specifically, if you can build a PoC with Yawning's or-ctl-filter that's what I would go for, since I'm not actually sure what's the current state of the OnioNS code, and how easy it will be to plug namecoin in there. What would be the procedure for third-party people with TBB to install namecoin + or-ctl-filter? Would it be a painful UX? FWIW, I'm also not sure what's the state of Jeff Burdges' name resolution idea, whether there are any plans on moving forward, and whether it would fit the Namecoin API.
George Kadianakis:
Hello Jeremy,
Hi George, thanks for the reply.
I'm a big noob when it comes to blockchains, namecoin, SPV clients and such, so I'm mainly going to focus on how to integrate this with Tor.
I know this isn't necessarily needed given that this would start out as an optional thing, but I'm curious: does Tor have people these days who are familiar with blockchain stuff? I know it's not particularly relevant to the core of what Tor does, so I'd be unsurprised if the answer is "not really", but I figure asking can't hurt.
It seems to me that a plausible way to kickstart this big project would be to make an unofficial add-on for TBB that can do the namecoin dance. People can then install it and experiment with it. If it fits the Tor use case well, then a community might be formed that will push this project forward even more.
Yes, this sounds good to me.
If it's an optional add-on, we also don't have to worry that much about the 400MB blockchain size, since it's gonna be optional and only people who want it will have to download it. This way we can learn how much of a problem the download size is anyway (it seems to me like a total blocker for people in non-western fast-internet countries).
FWIW, the 400 MB that I listed is the size of a LevelDB database after synchronizing a name database against the most recent year of blocks. This may not be representative of the data downloaded, for a few reasons: 1. If a name is updated more often than the expiration period, the download size will be higher. 2. LevelDB has storage overhead due to indexing, which will make the download size be lower. 3. If an API server is used for lookups, then only the block headers need to be downloaded, which makes the download size a lot lower. (Hence why it takes 5 minutes to sync rather than 10 minutes.) 4. There are a number of optimizations that can be made to decrease the download size, some of which are easier than others. Some of the optimizations that come to mind include checkpoints, UTXO commitments, UNO commitments, SegVal, and DMMS improvements. That said -- I definitely agree with you that real-world experimentation is a useful way to learn how much of an issue this really is. If it turns out to be totally usable in its current form, then we can deprioritize further optimizations, whereas if there are major issues in this department, then we would probably want to bump up the priority of optimizations. In particular, checkpoints are low-hanging fruit.
That's why I would suggest experimenting with the first two approaches you mentioned that don't require a modification to Tor's protocol.
Agreed.
Specifically, if you can build a PoC with Yawning's or-ctl-filter that's what I would go for, since I'm not actually sure what's the current state of the OnioNS code, and how easy it will be to plug namecoin in there.
That's very good to hear that you suggest this, because the Namecoin devs who would be likely to work on this (including me) prefer Go over C++, and we already have Go libraries that are likely to be reasonably straightforward to integrate into or-ctl-filter.
What would be the procedure for third-party people with TBB to install namecoin + or-ctl-filter? Would it be a painful UX?
To be honest, while I've examined the code for or-ctl-filter, I've never gone through the process of installing it, so I'm unsure of how the UX would be there. On Namecoin's end, it would basically consist of running a Java program; the Go library that we would hook into or-ctl-filter will simply return a resolution error for Namecoin lookups until the Java SPV client has finished syncing the blockchain; after the syncup finishes, Namecoin lookups automatically start working. So, the UX is unlikely to be much worse than a vanilla or-ctl-filter installation, unless there's something I haven't thought of.
FWIW, I'm also not sure what's the state of Jeff Burdges' name resolution idea, whether there are any plans on moving forward, and whether it would fit the Namecoin API.
Yes, I was under the impression that not much has happened on that front lately. Looks like we don't need to worry about it short-term. Thanks again for the feedback -- much appreciated. Cheers, -Jeremy
George Kadianakis <desnacked@riseup.net> writes:
[ text/plain ] Jeremy Rand <jeremyrand@airmail.cc> writes:
[ text/plain ] Hello Tor devs,
Namecoin is interested in collaboration with Tor in relation to human-readable .onion names; I'm reaching out to see how open the Tor community would be to this, and to get feedback on how exactly the integration might work.
The new hidden service spec is going to substantially increase the length of .onion names, which presents usability concerns. Namecoin provides a way to resolve a human-readable .bit name to a .onion name. Another benefit of Namecoin is that it provides a way to lookup TLS fingerprints for clearnet .bit sites, which reduces the risk of MITM attacks on clearnet websites from malicious or compromised CA's.
<snip>
There are a few options I can think of for integrating this with Tor for .onion naming. One would be to modify OnioNS to call the Namecoin SPV client. This would concern me because OnioNS is in C++, which introduces the risk of memory safety vulnerabilities. Another would be to use an intermediate proxy like Yawning's or-ctl-filter. A third option would be to try to get external name resolution implemented in Tor itself, which I believe Jeff Burdges has suggested in the past. If Option A or B is used, any solution would need to pass the stream isolation info to the SPV client.
Hello Jeremy,
I'm a big noob when it comes to blockchains, namecoin, SPV clients and such, so I'm mainly going to focus on how to integrate this with Tor.
It seems to me that a plausible way to kickstart this big project would be to make an unofficial add-on for TBB that can do the namecoin dance. People can then install it and experiment with it. If it fits the Tor use case well, then a community might be formed that will push this project forward even more.
If it's an optional add-on, we also don't have to worry that much about the 400MB blockchain size, since it's gonna be optional and only people who want it will have to download it. This way we can learn how much of a problem the download size is anyway (it seems to me like a total blocker for people in non-western fast-internet countries).
That's why I would suggest experimenting with the first two approaches you mentioned that don't require a modification to Tor's protocol.
On this front, please check out Nick's new mail showing how to integrate external name resolvers into Tor: https://lists.torproject.org/pipermail/tor-dev/2016-August/011253.html
I'm also a noob, so just to be clear, is the goal here to adopt namecoin as a naming mechanism for hidden services or is the goal to enable a generic extension mechanism where multiple different naming solutions can be experimented with and namecoin wants to build the code to leverage that mechanism so it can be part of the more general naming experiment? Thanks, Yaron -----Original Message----- From: tor-dev [mailto:tor-dev-bounces@lists.torproject.org] On Behalf Of George Kadianakis Sent: Tuesday, August 2, 2016 6:54 AM To: Jeremy Rand <jeremyrand@airmail.cc>; Tor-Dev <tor-dev@lists.torproject.org> Subject: Re: [tor-dev] Tor and Namecoin George Kadianakis <desnacked@riseup.net> writes:
[ text/plain ] Jeremy Rand <jeremyrand@airmail.cc> writes:
[ text/plain ] Hello Tor devs,
Namecoin is interested in collaboration with Tor in relation to human-readable .onion names; I'm reaching out to see how open the Tor community would be to this, and to get feedback on how exactly the integration might work.
The new hidden service spec is going to substantially increase the length of .onion names, which presents usability concerns. Namecoin provides a way to resolve a human-readable .bit name to a .onion name. Another benefit of Namecoin is that it provides a way to lookup TLS fingerprints for clearnet .bit sites, which reduces the risk of MITM attacks on clearnet websites from malicious or compromised CA's.
<snip>
There are a few options I can think of for integrating this with Tor for .onion naming. One would be to modify OnioNS to call the Namecoin SPV client. This would concern me because OnioNS is in C++, which introduces the risk of memory safety vulnerabilities. Another would be to use an intermediate proxy like Yawning's or-ctl-filter. A third option would be to try to get external name resolution implemented in Tor itself, which I believe Jeff Burdges has suggested in the past. If Option A or B is used, any solution would need to pass the stream isolation info to the SPV client.
Hello Jeremy,
I'm a big noob when it comes to blockchains, namecoin, SPV clients and such, so I'm mainly going to focus on how to integrate this with Tor.
It seems to me that a plausible way to kickstart this big project would be to make an unofficial add-on for TBB that can do the namecoin dance. People can then install it and experiment with it. If it fits the Tor use case well, then a community might be formed that will push this project forward even more.
If it's an optional add-on, we also don't have to worry that much about the 400MB blockchain size, since it's gonna be optional and only people who want it will have to download it. This way we can learn how much of a problem the download size is anyway (it seems to me like a total blocker for people in non-western fast-internet countries).
That's why I would suggest experimenting with the first two approaches you mentioned that don't require a modification to Tor's protocol.
On this front, please check out Nick's new mail showing how to integrate external name resolvers into Tor: https://lists.torproject.org/pipermail/tor-dev/2016-August/011253.html _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Yaron Goland:
I'm also a noob, so just to be clear, is the goal here to adopt namecoin as a naming mechanism for hidden services or is the goal to enable a generic extension mechanism where multiple different naming solutions can be experimented with and namecoin wants to build the code to leverage that mechanism so it can be part of the more general naming experiment?
Thanks,
Yaron
Hi Yaron, My personal take on this is that modularity and reusability are good design principles to aim for. As such, I think it would be good for any solution to allow multiple naming systems (not just Namecoin) to be used with Tor, and similarly, multiple hidden-service-like systems (e.g. Tor, I2P, Freenet, ZeroNet, IPFS, and MaidSafe) would ideally be usable with Namecoin (and whatever other naming systems might be used). Of course, this might be difficult to achive in a completely general case, but the amount of added code needed to add a new naming system or new hidden-service-like system would ideally be as small as possible. For this reason, I think using or-ctl-filter would have an advantage here, since it also can be used with I2P, whereas Nick's suggestion of using the Tor controller API appears to be fairly specialized to Tor. All that said -- my opinion is that Namecoin does offer a combination of properties that aren't really offered by any other systems, and that that particular combination is very useful for Tor hidden services (particularly given that the length of .onion names is going to be made a lot longer). So I would love to see Namecoin be adopted by Tor. I do understand, though, that this would mean a lot of review that hasn't happened yet. I'd be happy to work with Tor to facilitate that, if there's interest. And, of course, it's likely that my opinion of Namecoin isn't exactly impartial, seeing as I'm one of the Namecoin developers. I do think that enabling people to more easily experiment with combining Namecoin and Tor hidden services seems to be a prudent step to take before any kind of adoption of Namecoin by Tor. Hope this answers your inquiry -- let me know if I was unclear about anything. Cheers, -Jeremy
First Jeremy, thanks for engaging with Tor! Some kind of solution is going to be needed. But I think if we carefully leverage either DNS or URLs (I prefer the later but that's just me) then we can easily support multiple different naming systems without them running rough shod over each other. In other words we could have a URL of the form tornc+http:foobar/index.html or alternatively https://foobar.tornc/index.html (where we are using tornc in the same sense as .onion). Different Tor clients can decide which name resolvers they want to support and let users decide which one has the best solution. Thanks, Yaron -----Original Message----- From: tor-dev [mailto:tor-dev-bounces@lists.torproject.org] On Behalf Of Jeremy Rand Sent: Tuesday, August 2, 2016 3:30 PM To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] Tor and Namecoin Yaron Goland:
I'm also a noob, so just to be clear, is the goal here to adopt namecoin as a naming mechanism for hidden services or is the goal to enable a generic extension mechanism where multiple different naming solutions can be experimented with and namecoin wants to build the code to leverage that mechanism so it can be part of the more general naming experiment?
Thanks,
Yaron
Hi Yaron, My personal take on this is that modularity and reusability are good design principles to aim for. As such, I think it would be good for any solution to allow multiple naming systems (not just Namecoin) to be used with Tor, and similarly, multiple hidden-service-like systems (e.g. Tor, I2P, Freenet, ZeroNet, IPFS, and MaidSafe) would ideally be usable with Namecoin (and whatever other naming systems might be used). Of course, this might be difficult to achive in a completely general case, but the amount of added code needed to add a new naming system or new hidden-service-like system would ideally be as small as possible. For this reason, I think using or-ctl-filter would have an advantage here, since it also can be used with I2P, whereas Nick's suggestion of using the Tor controller API appears to be fairly specialized to Tor. All that said -- my opinion is that Namecoin does offer a combination of properties that aren't really offered by any other systems, and that that particular combination is very useful for Tor hidden services (particularly given that the length of .onion names is going to be made a lot longer). So I would love to see Namecoin be adopted by Tor. I do understand, though, that this would mean a lot of review that hasn't happened yet. I'd be happy to work with Tor to facilitate that, if there's interest. And, of course, it's likely that my opinion of Namecoin isn't exactly impartial, seeing as I'm one of the Namecoin developers. I do think that enabling people to more easily experiment with combining Namecoin and Tor hidden services seems to be a prudent step to take before any kind of adoption of Namecoin by Tor. Hope this answers your inquiry -- let me know if I was unclear about anything. Cheers, -Jeremy
participants (4)
-
George Kadianakis -
Jeremy Rand -
Spencer -
Yaron Goland