Re: [tor-dev] Naming Systems wiki page
On 09/27/2016 02:39 AM, Jeremy Rand wrote: > Relatedly -- I had some trouble summarizing some of the items in the > Namecoin section because the security, privacy, and scalability > properties of Namecoin are somewhat different depending on whether the > user is using a full node (downloads the entire blockchain), a FBR-C > node (receives full blocks that can contain current name transactions), > or a headers-only node (receives only block headers). > > I didn't want to change the layout of the page much without asking, but > would it make sense to split the Namecoin section into multiple sections > (a section for each of those node types)? Or is it preferred to keep > them in 1 section and say which of the security properties / drawbacks > apply to which node types (which is what I've done for the moment)? This is a fair point. I agree that we should split it up accordingly to "Namecoin (full blockchain)" and "Namecoin (thin/SPV client)". Both have different descriptions, security properties, and drawbacks so it would probably be more organized this way. -- Jesse signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Naming Systems wiki page
On 09/27/2016 02:27 AM, Jeremy Rand wrote: > Hello! I just had a chance to look through the latest state of the wiki > page (thanks to everyone who's been expanding it). I've added several > items to the security properties and drawbacks sections of Namecoin, and > made a few trivial corrections; hopefully none of them are > controversial. (If anyone thinks I made a mistake, please let me know.) > > I notice that kernelcorn added an item to the "drawbacks" section of > Namecoin, which says "Hard to authenticate names." It's not entirely > clear to me what is meant by this item, so it's hard for me to evaluate > its accuracy. > > Any chance Jesse could elaborate on this? My mistake. I was thinking about authenticating the RSA keys with Namecoin's ECC keys, but after further thought this is not a proper criticism so I have removed it. Since you're checking factual accuracy of the items in the wiki, you can find the OnioNS pre-print here: https://github.com/Jesse-V/OnioNS-literature/raw/master/conference/conference.pdf > PS: Happy to see that OnioNS is still being worked on -- I think it's > great to have more of the solution space explored and more options > available, regardless of the fact that OnioNS and Namecoin could be > considered competitors. We're all in this together, and I'd love to see > both OnioNS and Namecoin succeed. :) Namecoin is the closest competitor. They are very different designs of course. In any event, naming systems should become more desirable once proposal 224 is deployed. I'm also competing with OnionBalance now since OnioNS supports basic load-balancing at the name level. :) -- Jesse signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Naming Systems wiki page
Jesse V: > On 09/27/2016 02:39 AM, Jeremy Rand wrote: >> Relatedly -- I had some trouble summarizing some of the items in the >> Namecoin section because the security, privacy, and scalability >> properties of Namecoin are somewhat different depending on whether the >> user is using a full node (downloads the entire blockchain), a FBR-C >> node (receives full blocks that can contain current name transactions), >> or a headers-only node (receives only block headers). >> >> I didn't want to change the layout of the page much without asking, but >> would it make sense to split the Namecoin section into multiple sections >> (a section for each of those node types)? Or is it preferred to keep >> them in 1 section and say which of the security properties / drawbacks >> apply to which node types (which is what I've done for the moment)? > > This is a fair point. I agree that we should split it up accordingly to > "Namecoin (full blockchain)" and "Namecoin (thin/SPV client)". Both have > different descriptions, security properties, and drawbacks so it would > probably be more organized this way. Sounds good. I'm happy to do the split, but it might take me a few days before I have the time to make those edits. Cheers, -Jeremy signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Naming Systems wiki page
Jesse V: > On 09/27/2016 02:27 AM, Jeremy Rand wrote: >> Hello! I just had a chance to look through the latest state of the wiki >> page (thanks to everyone who's been expanding it). I've added several >> items to the security properties and drawbacks sections of Namecoin, and >> made a few trivial corrections; hopefully none of them are >> controversial. (If anyone thinks I made a mistake, please let me know.) >> >> I notice that kernelcorn added an item to the "drawbacks" section of >> Namecoin, which says "Hard to authenticate names." It's not entirely >> clear to me what is meant by this item, so it's hard for me to evaluate >> its accuracy. >> >> Any chance Jesse could elaborate on this? > > My mistake. I was thinking about authenticating the RSA keys with > Namecoin's ECC keys, but after further thought this is not a proper > criticism so I have removed it. Thanks. > Since you're checking factual accuracy of the items in the wiki, you can > find the OnioNS pre-print here: > https://github.com/Jesse-V/OnioNS-literature/raw/master/conference/conference.pdf Ah, excellent, some reading material! Much appreciated, I'll read through that when I next catch a break. I'm quite curious to see how things have evolved since I last checked out OnioNS in any detail (which would have been about a year ago, I guess). >> PS: Happy to see that OnioNS is still being worked on -- I think it's >> great to have more of the solution space explored and more options >> available, regardless of the fact that OnioNS and Namecoin could be >> considered competitors. We're all in this together, and I'd love to see >> both OnioNS and Namecoin succeed. :) > > Namecoin is the closest competitor. They are very different designs of > course. In any event, naming systems should become more desirable once > proposal 224 is deployed. Yes, 224 seems to be making systems like OnioNS and Namecoin quite a bit more urgently useful. > I'm also competing with OnionBalance now since OnioNS supports basic > load-balancing at the name level. :) Namecoin also can be used for name-level load balancing, although I haven't really carefully considered the anonymity effects of the load balancing (e.g. does it open the risk of fingerprinting?), so that feature is lower priority until I can think about that more carefully. I'm curious how OnioNS is handling that -- maybe there's some thinking in OnioNS's design that's adaptable to Namecoin? Cheers, -Jeremy signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
I'll add a note on GNS to your wiki George, but.. On Sat, 2016-08-20 at 16:48 +0300, George Kadianakis wrote: > We really need to start serious work in this area ASAP! Maybe let's > start by > making a wiki page that lists the various potential solutions (GNS, > Namecoin, > Blockstack, OnioNS, etc.)? There were a couple reasons I stopped the work on integrating GNS with Tor, which Christian asked me to do : First, I did not like that users could confirm that a particular subdomain exists if they know the base domain's public key. Second, I disliked the absence of the collaborative random number generator protections you guys added to Tor. Now my first concern is not an issue in the context of a "name system" for servers, well it's clearly desirable there. It's just not desirable if you start talking about using the name system for more social applications, which people do for GNS. Also, my second concern is not an issue if you envision the system being backed only by Tor HS record, not GNS records. In that scenario, the cost you pay is (1) you need a forwarding record for Tor HSs, and (2) sites with subdomains need to continually reupload those them as the collaborative random number changes. This does not give you global names obviously, but it does give you GNS style non-global names in the threat model desired by the 224 or whatever. In effect, you'd use the existing HSDirs for non-global name links, instead of some new PIR scheme like U+039B and others proposed. Now non-global names are not necessarily useful unless people can socially construct naming hierarchies around them, but that's doable. And they can refer to each other. etc. Anyways, I think adding forwarding records and the signing key derivation trick from GNS to Tor might give the Tor project a way to let different naming schemes develop organically. And not be overly responsible for issues arising from Zooko's triangle. tl;dr I'm not saying GNS itself is the way to go, but GNS's subdomoman crypto trick along with Tor's existing HSDir structure might improve things. Jeff signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Reducing initial onion descriptor upload delay (down to 0s?)
Hi tor-dev@, Ivan Markin: > IMO an onion service should publish its first descriptor instantly. If > something happens afterwards and one has to fix the descriptor - deal > with it with backoff/delay to prevent DoS on HSDirs. > I think that most of the ephemeral services are not going to use more > than one descriptor. Moreover, they are going to use just one > introduction point. So it's not a big deal if one of the published IPs > fails since a client is going to use one of the rest. > Also note the reachability issue I mentioned. > > teor: > > It would be nice to have this change in 0.2.9 for Single Onion > > Services and I think also for HSs with OnionBalance Can we actually have this in 029? If yes, how should we do it exactly? This issue gets more and more annoying. Mostly because of the (un-)reachability issue. -- Ivan Markin ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Naming Systems wiki page
On 09/27/2016 10:05 AM, Jeremy Rand wrote: > Namecoin also can be used for name-level load balancing, although I > haven't really carefully considered the anonymity effects of the load > balancing (e.g. does it open the risk of fingerprinting?), so that > feature is lower priority until I can think about that more carefully. > I'm curious how OnioNS is handling that -- maybe there's some thinking > in OnioNS's design that's adaptable to Namecoin? Really? Now I'm curious how Namecoin does it! OnioNS currently achieves load balancing by allowing the onion service operator to specify a list of secondary addresses. In this case, the name record contains the following: + RSA-1024 onion service public key + RSA-1024 signature + memorable name + secondary addresses + + "address1.onion" + + "address2.onion" + (other data) The client will then randomly select address1.onion or address2.onion and will round-robin until one of them connects. It's a very simple scheme. Right now it looks like this: https://github.com/Jesse-V/OnioNS-common/blob/8217c47bce76d87d056f1bab671c44e13f1e9d69/src/records/Record.cpp#L58 OnioNS also checks that the main public key is in the root directory of each of the secondary addresses to ensure that they are all maintained by the same entity. I am still mulling over possible attacks, defenses, and implications, but in general it seems to work. -- Jesse signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Naming Systems wiki page
Jesse V: > On 09/27/2016 10:05 AM, Jeremy Rand wrote: >> Namecoin also can be used for name-level load balancing, although I >> haven't really carefully considered the anonymity effects of the load >> balancing (e.g. does it open the risk of fingerprinting?), so that >> feature is lower priority until I can think about that more carefully. >> I'm curious how OnioNS is handling that -- maybe there's some thinking >> in OnioNS's design that's adaptable to Namecoin? > > Really? Now I'm curious how Namecoin does it! > > OnioNS currently achieves load balancing by allowing the onion service > operator to specify a list of secondary addresses. In this case, the > name record contains the following: > + RSA-1024 onion service public key > + RSA-1024 signature > + memorable name > + secondary addresses > + + "address1.onion" > + + "address2.onion" > + (other data) > > The client will then randomly select address1.onion or address2.onion > and will round-robin until one of them connects. It's a very simple > scheme. Right now it looks like this: > https://github.com/Jesse-V/OnioNS-common/blob/8217c47bce76d87d056f1bab671c44e13f1e9d69/src/records/Record.cpp#L58 > > OnioNS also checks that the main public key is in the root directory of > each of the secondary addresses to ensure that they are all maintained > by the same entity. I am still mulling over possible attacks, defenses, > and implications, but in general it seems to work. So, I admit that I haven't explicitly specced this out yet (or, rather, I started speccing it out in my head, but never really finished fleshing it out), but here's roughly what I was planning. I was actually meaning to ask you (and the other Tor people) what you think of this rough design, as I'm curious if I've overlooked any attacks. (I'm typing this from memory, so I might have a few details wrong.) Namecoin would have 2 namespaces for this purpose: the d/ namespace (which is used for all domain names), and the onion/ namespace (a new namespace whose purpose I will discuss below). Let's say that "debian.bit" is desired to map to a load balance between "abc.onion" and "xyz.onion". The name owner would register 3 names: d/debian, onion/abc/nonce1, and onion/xyz/nonce2. d/debian would include the following data (in a JSON-based format that also allows it to include things like IP addresses, other DNS records, etc.): abc.onion nonce1 xyz.onion nonce2 So in other words, d/debian includes all of the .onion addresses that are pointed to, and the nonces that are needed to find the other names. Just like in a Bitcoin transaction, this JSON data is signed by the ECDSA key that owns d/debian. onion/abc/nonce1 contains the following data: Onion pubkey for abc.onion Signature of "d/debian", signed by the onion pubkey for abc.onion onion/xyz/nonce2 works similarly, just with the onion pubkey for xyz.onion. This has a few properties that I think are useful: 1. The human-readable name signs each .onion address. 2. Each .onion address signs the human-readable name. 3. Given the human-readable name, all of the .onion addresses can be easily found. 4. Given an .onion address, a prefix-based lookup (i.e. not specifying the nonce) will yield the human-readable name. (So if a user visits a .onion site, hypothetically Tor Browser could detect before you connect that there's a Namecoin name for that .onion, and either automatically redirect to the Namecoin name or give the user the choice of doing so.) 5. Since a nonce is present for the onion/ names, the worst that squatters can accomplish is increasing the amount of data that needs to be downloaded by the prefix search in order to find the human-readable name. (It would be even nicer if we could make the Onion signature part of blockchain validation rules, but that would violate a Namecoin design goal of being agnostic to the format of the data stored in a name.) Revocation and/or expiration for the signatures by the .onion pubkey could, in principle, be added to this scheme if needed, it just adds complexity. Expiration and revocation could both be done by making the Onion signature also include a min/max block height and a revocation boolean flag in the signed data. I haven't carefully thought about that topic yet. The main concerns I have with this approach (that I remember offhand) are: 1. Does signing this data with the Onion keys lead to cross-protocol attacks? Is that avoidable by structuring the signed data in some way? I'm not familiar enough with the Tor protocol to know for sure right now. 2. Does the use of a nonce sufficiently prevent spam attacks? 3. Will the Onion pubkeys and signatures eat up too much space in the Namecoin blockchain? It might not be a problem in practice since the number of onion services is so small, but I admit that I haven't crunched the numbers on that. 4. What's the right method of choosing which onion service to use if multiple ones are listed? Choosing randomly on every request might co
