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
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 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] 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
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
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
Jeremy Rand: > George Kadianakis: >> >> I made a wiki page for Naming Systems here: >> https://trac.torproject.org/projects/tor/wiki/doc/OnionServiceNamingSystems >> >> Feel free to start adding information and links and make it look nicer. >> >> Let's try to build a good knowledge base that will help us take informed >> decisions. Please try to maintain some sort of consistent structure through >> the >> document. >> >> (In the unlikely case where the doc gets out of hand, I will try to find some >> time to curate it.) >> >> Thanks! :) > > 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? > > Cheers, > -Jeremy > > 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. :) 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)? 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
[tor-dev] Naming Systems wiki page
George Kadianakis: > > I made a wiki page for Naming Systems here: > https://trac.torproject.org/projects/tor/wiki/doc/OnionServiceNamingSystems > > Feel free to start adding information and links and make it look nicer. > > Let's try to build a good knowledge base that will help us take informed > decisions. Please try to maintain some sort of consistent structure through > the > document. > > (In the unlikely case where the doc gets out of hand, I will try to find some > time to curate it.) > > Thanks! :) 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? Cheers, -Jeremy 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. :) 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