Hello people,
this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal.
Anyway, after prop224 gets implemented, we will go from 16-character onion addresses to 52-character onion addresses. See here for more details: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
This happens because we want the onion address to be a real public key, and not the truncated hash of a public key as it is now. We want that so that we can do fun cryptography with that public key. Specifically, we want to do key blinding as specified here: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
As I understand it the key blinding scheme is trying to achieve the following properties: a) Every HS has a permanent identity onion address b) Clients use an ephemeral address to fetch descriptors from HSDir c) Knowing the ephemeral address never reveals the permanent onion address c) Descriptors are encrypted and can only be read by clients that know the identity onion key d) Descriptors are signed and verifiable by clients who know the identity onion key e) Descriptors are also verifiable in a weaker manner by HSDirs who know the ephemeral address
In this email I'm going to sketch a scheme that has all above properties except from (e).
The suggested scheme is basically the current HSDir protocol, but with clients using ephemeral addresses for fetching HS descriptors. Also, we truncate onion address hashes to something larger than 80bits.
Here is a sketch of the scheme:
------
Hidden service Alice has a long-term public identity key: A Hidden service Alice has a long-term private identity key: a
The onion address of Alice, as in the current scheme, is a truncated H(A). So let's say: onion_address = H(A) truncated to 128 bits.
The full public key A is contained in Alice's descriptor as it's currently the case.
When Alice wants to publish a descriptor she computes an ephemeral address based on the current time period 't': ephemeral_address = H(t || onion_address)
Legitimate clients who want to fetch the descriptor also do the same, since they know both 't' and 'onion_address'.
Descriptors are encrypted using a key derived from the onion_address. Hence, only clients that know the onion_address can decrypt it.
Descriptors are signed using the long-term private key of the hidden service, and can be verified by clients who manage to decrypt the descriptor.
---
Assuming the above is correct and makes sense (need more brain), it should maintain all the security properties above except from (e).
So basically in this scheme, HSDirs won't be able to verify the signatures of received descriptors.
The obvious question here is, is this a problem?
IIUC, having the HSDirs verify those signatures does not offer any additional security, except from making sure that the descriptor signature was actually created using a legitimate ed25519 key. Other than that, I don't see it offering much.
So, what does this additional HSDir verification offer? It seems like a weak way to ensure that no garbage is uploaded on the HSDir hash ring. However, any reasonable attacker will put their garbage in a descriptor and sign it with a random ed25519 key, and it will trivially pass the HSDir validation.
So do we actually care about this property enough to introduce huge onion addresses to the system?
Please discuss and poke holes at the above system.
Cheers!
On Fri, Jul 29, 2016 at 11:26 AM, George Kadianakis desnacked@riseup.net wrote:
So basically in this scheme, HSDirs won't be able to verify the signatures of received descriptors.
The obvious question here is, is this a problem?
I'm not sure I fully understand, so here's a couple of quick questions before I look more deeply. (I'm assuming that descriptors are indexed by their ephemeral address here. If that's wrong and they're indexed by something other than than ephemeral address, my analysis is wrong.)
1) In your scheme, how does descriptor replacement work? In the current scheme, if my introduction points change, I can upload a new descriptor. In this scheme, it seems that either _anyone_ can upload a new descriptor with the same ephemeral address (which is insecure), or descriptors cannot be replaced (which is problematic).
2) Even if descriptors can't be replaced, there's still a problem: What stops an attacker from racing the hidden service to try to upload their own competing descriptor with the same ephemeral address?
Nick Mathewson nickm@alum.mit.edu writes:
[ text/plain ] On Fri, Jul 29, 2016 at 11:26 AM, George Kadianakis desnacked@riseup.net wrote:
So basically in this scheme, HSDirs won't be able to verify the signatures of received descriptors.
The obvious question here is, is this a problem?
I'm not sure I fully understand, so here's a couple of quick questions before I look more deeply. (I'm assuming that descriptors are indexed by their ephemeral address here. If that's wrong and they're indexed by something other than than ephemeral address, my analysis is wrong.)
- In your scheme, how does descriptor replacement work? In the
current scheme, if my introduction points change, I can upload a new descriptor. In this scheme, it seems that either _anyone_ can upload a new descriptor with the same ephemeral address (which is insecure), or descriptors cannot be replaced (which is problematic).
- Even if descriptors can't be replaced, there's still a problem:
What stops an attacker from racing the hidden service to try to upload their own competing descriptor with the same ephemeral address?
Oops, you are absolutely right! :)
Seems like security property (e) from the previous email was much more important than I thought! The HSDir must indeed be able to validate that a descriptor was signed using a particular ephemeral key (which then maps to a particular identity key).
OK, here is another brainstormy attempt at shortening onion addresses post-prop224, while maintaining the same security properties:
Can we use HSDirs to store encrypted identity keys for HSes, along with the encrypted descriptors? When clients query the HSDir, they fetch both the encrypted identity key and the encrypted descriptor, and use the former to decrypt the latter.
Let me try to make this more formal by stating some definitions from prop224:
A is the identity public key of the HS A_t is the ephemeral blinded key of the HS for time period t E(desc) is the encrypted HS descriptor using key H(t||A) exactly as in prop224
Now let's introduce some new notions:
- onion_address = H(A || "onion_address") truncated to 128 bits onion_address is the string that clients need to know to connect to an HS. - query_key = H(onion_address || t || "query_key") query_key is used to query the HSDir for HS information. Specifically for the encrypted HS identity key and the encrypted descriptor of the HS. - encryption_key = H(onion_address || t || "encryption_key") encryption_key is used to encrypt the identity key A of the HS so that it's hidden from entities who don't know the onion_address (like HSDirs).
- identity_key_ciphertext = E_encryption_key(A)
identity_key_ciphertext is the identity key of the HS encrypted using encryption_key.
Now for the protocol part:
In current prop224, the HS uploads to the HSDir its ephemeral blinded key A_t, and its encrypted descriptor E(desc). That remains the same in this scheme, but the HS also uploads the query_key and identity_key_ciphertext to the HSDir. The HSDir verifies the descriptor signature as normal, and uses query_key as the index for all that information.
Now, a client who wants to connect to that HS, uses the onion_address to derive the query_key, and sends query_key to the HSDir. The HSDir then checks its index, and returns to the client the encrypted descriptor E(desc) and also the identity_key_ciphertext.
The client at this point derives encryption_key using the onion_address, and decrypts the identity_key_ciphertext. After the client does so, the client knows A and can decrypt and verify the descriptor ciphertext as normal.
Does this make sense?
The idea is that we use HSDirs for PKI along with descriptor storage. We basically encrypt the identity key of the HS using the onion_address and store it in the HSDirs. We never reveal onion_address to the HSDirs.
Please let me know in what way this scheme is completely broken!
(I've received many concerns about the future size of onion addresses, and hence I feel obligated to hit my head against the wall some more.)
Cheers!
On 2016-07-29 17:26, George Kadianakis wrote:
Hello people,
this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal.
Anyway, after prop224 gets implemented, we will go from 16-character onion addresses to 52-character onion addresses. See here for more details:
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
This happens because we want the onion address to be a real public key, and not the truncated hash of a public key as it is now. We want that so that we can do fun cryptography with that public key. Specifically, we want to do key blinding as specified here:
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
As I understand it the key blinding scheme is trying to achieve the following properties: a) Every HS has a permanent identity onion address b) Clients use an ephemeral address to fetch descriptors from HSDir c) Knowing the ephemeral address never reveals the permanent onion address c) Descriptors are encrypted and can only be read by clients that know the identity onion key d) Descriptors are signed and verifiable by clients who know the identity onion key e) Descriptors are also verifiable in a weaker manner by HSDirs who know the ephemeral address
In this email I'm going to sketch a scheme that has all above properties except from (e).
The suggested scheme is basically the current HSDir protocol, but with clients using ephemeral addresses for fetching HS descriptors. Also, we truncate onion address hashes to something larger than 80bits.
Here is a sketch of the scheme:
Hidden service Alice has a long-term public identity key: A Hidden service Alice has a long-term private identity key: a
The onion address of Alice, as in the current scheme, is a truncated H(A). So let's say: onion_address = H(A) truncated to 128 bits.
The full public key A is contained in Alice's descriptor as it's currently the case.
When Alice wants to publish a descriptor she computes an ephemeral address based on the current time period 't': ephemeral_address = H(t || onion_address)
Legitimate clients who want to fetch the descriptor also do the same, since they know both 't' and 'onion_address'.
Descriptors are encrypted using a key derived from the onion_address. Hence, only clients that know the onion_address can decrypt it.
Descriptors are signed using the long-term private key of the hidden service, and can be verified by clients who manage to decrypt the descriptor.
Assuming the above is correct and makes sense (need more brain), it should maintain all the security properties above except from (e).
So basically in this scheme, HSDirs won't be able to verify the signatures of received descriptors.
The obvious question here is, is this a problem?
IIUC, having the HSDirs verify those signatures does not offer any additional security, except from making sure that the descriptor signature was actually created using a legitimate ed25519 key. Other than that, I don't see it offering much.
So, what does this additional HSDir verification offer? It seems like a weak way to ensure that no garbage is uploaded on the HSDir hash ring. However, any reasonable attacker will put their garbage in a descriptor and sign it with a random ed25519 key, and it will trivially pass the HSDir validation.
So do we actually care about this property enough to introduce huge onion addresses to the system?
Please discuss and poke holes at the above system.
Cheers! _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Speaking out of turn here:
Why not integrate kernelcorn's OnioNS project and keep all the current security properties?
OnioNS addresses are much more user friendly than even the shorter .onion addresses.
bancfc@openmailbox.org writes:
[ text/plain ] On 2016-07-29 17:26, George Kadianakis wrote:
Hello people,
this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal.
Anyway, after prop224 gets implemented, we will go from 16-character onion addresses to 52-character onion addresses. See here for more details:
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
This happens because we want the onion address to be a real public key, and not the truncated hash of a public key as it is now. We want that so that we can do fun cryptography with that public key. Specifically, we want to do key blinding as specified here:
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
Speaking out of turn here:
Why not integrate kernelcorn's OnioNS project and keep all the current security properties?
OnioNS addresses are much more user friendly than even the shorter .onion addresses.
Hello bancfc,
AFAIK, the OnioNS project was never actually finished nor deployed.
It also has various engineering/deployment issues that have not been addressed and it requires a whole infrastructure/community to work.
In general, I'm open to DNS-like approaches for hidden services, but if we can also improve the UX situation on the protocol layer, that seems like a win to me :)
George Kadianakis:
this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal.
Taking a step back here, I believe the size of the address to be a really minor usability problem. IPv6 adressses are 128 bits long, and plenty of people in this world now access content via IPv6. It's not a usability problem because they use a naming—as opposed to addressing—scheme to learn about the appropriate IPv6 address.
While I do think we should think of nicer representation for the new addresses than base32, and we should adress that, working on a naming system sounds like an easier way out to improve onion services usability than asking people to remember random addresses (be them 16 or 52 characters-long).
(I now plenty of people who type “riseup” in the Google search bar of their browser to access their mailbox… They don't even want to/can't remember an URL. Hardly a chance they will remember an onion address, whatever its size.)
Maybe it would be worthwhile to ask the UX team for input on the topic?
Hi,
Lunar: the size of the address
Size *does* matter XD
128 bits long
Oh my.
IPv6. It's not a usability problem because ..
.. no one outside of computer networking knows what it is, or that it exists (:
a naming system [vs] random[ness] [regarding] the size of onion addresses after proposal 224 gets implemented
Clarity is always a plus (:
If the story is that people are remembering their shit, readability increases the probability of associative memory formation.
Google search bar of browser
Silly redundancy; why have two search bars next to each other q:
to access [all the mails]
x@y.z in the address bar has been known to prompt sign in.
Searching can be a security tactic.
Wordlife, Spencer
I agree with this, I don't really see the point of making .onion names easy to remember. If it's a service you access often, you can bookmark it or alias it locally to something like "myserver.onion" (maybe we should make it easier for users to do just that - an alias file for .onion lookups, allowing them to register myserver.onion and point it to asdlataoireaoiasdasd.onion or whatever).
If it's a link on a Wiki or in a search engine, you just click on it, you don't care what the name is. The only time you'd have to remember an actual .onion address is if you heard it on the radio or saw a banner on the side of the street while driving and had to memorize it in a few seconds. Or maybe if you have to read the address _over the phone_ to a friend (as opposed to mailing him the link).
What is the exact use case of this? I'm not saying it's useless, I just don't see the point, maybe I'm missing something.
Razvan
-- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL
On Sat, Jul 30, 2016 at 9:44 PM, Lunar lunar@torproject.org wrote:
George Kadianakis:
this is an experimental mail meant to address legitimate usability
concerns
with the size of onion addresses after proposal 224 gets implemented.
It's
meant for discussion and it's far from a full blown proposal.
Taking a step back here, I believe the size of the address to be a really minor usability problem. IPv6 adressses are 128 bits long, and plenty of people in this world now access content via IPv6. It's not a usability problem because they use a naming—as opposed to addressing—scheme to learn about the appropriate IPv6 address.
While I do think we should think of nicer representation for the new addresses than base32, and we should adress that, working on a naming system sounds like an easier way out to improve onion services usability than asking people to remember random addresses (be them 16 or 52 characters-long).
(I now plenty of people who type “riseup” in the Google search bar of their browser to access their mailbox… They don't even want to/can't remember an URL. Hardly a chance they will remember an onion address, whatever its size.)
Maybe it would be worthwhile to ask the UX team for input on the topic?
-- Lunar lunar@torproject.org
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
In order to have an effective system of blinded identities, you need to have an out of band channel to transmit 128-256 bits from the server to the client. This is essential for blinding the in-band adversary to the long term shared identity between the client and server. A naming system will move that blinding data back into the in-band channel.
There needs to be better tools for working with 128-256 bits of data.
We have bookmarks, QR codes, and word lists etc but there is tons of room for improvement.
It seems impossible to strongly blind an in band adversary while moving fewer bits through the address channel.
On Sun, Jul 31, 2016 at 8:03 AM Razvan Dragomirescu < razvan.dragomirescu@veri.fi> wrote:
I agree with this, I don't really see the point of making .onion names easy to remember. If it's a service you access often, you can bookmark it or alias it locally to something like "myserver.onion" (maybe we should make it easier for users to do just that - an alias file for .onion lookups, allowing them to register myserver.onion and point it to asdlataoireaoiasdasd.onion or whatever).
If it's a link on a Wiki or in a search engine, you just click on it, you don't care what the name is. The only time you'd have to remember an actual .onion address is if you heard it on the radio or saw a banner on the side of the street while driving and had to memorize it in a few seconds. Or maybe if you have to read the address _over the phone_ to a friend (as opposed to mailing him the link).
What is the exact use case of this? I'm not saying it's useless, I just don't see the point, maybe I'm missing something.
Razvan
-- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL
On Sat, Jul 30, 2016 at 9:44 PM, Lunar lunar@torproject.org wrote:
George Kadianakis:
this is an experimental mail meant to address legitimate usability
concerns
with the size of onion addresses after proposal 224 gets implemented.
It's
meant for discussion and it's far from a full blown proposal.
Taking a step back here, I believe the size of the address to be a really minor usability problem. IPv6 adressses are 128 bits long, and plenty of people in this world now access content via IPv6. It's not a usability problem because they use a naming—as opposed to addressing—scheme to learn about the appropriate IPv6 address.
While I do think we should think of nicer representation for the new addresses than base32, and we should adress that, working on a naming system sounds like an easier way out to improve onion services usability than asking people to remember random addresses (be them 16 or 52 characters-long).
(I now plenty of people who type “riseup” in the Google search bar of their browser to access their mailbox… They don't even want to/can't remember an URL. Hardly a chance they will remember an onion address, whatever its size.)
Maybe it would be worthwhile to ask the UX team for input on the topic?
-- Lunar lunar@torproject.org
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Lunar lunar@torproject.org writes:
[ text/plain ] George Kadianakis:
this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal.
Taking a step back here, I believe the size of the address to be a really minor usability problem. IPv6 adressses are 128 bits long, and plenty of people in this world now access content via IPv6. It's not a usability problem because they use a naming—as opposed to addressing—scheme to learn about the appropriate IPv6 address.
That's true. Naming systems are indeed the way to go wrt UX. The future sucks if our users are supposed to use 24 (or 56) random characters as addresses.
That said, the current IPv6 naming scheme (DNS) is far from perfect as well. Tor would never use it (or any other system with similar threat model).
Furthermore, all the _secure naming systems_ that have been suggested have their own tradeoffs. They are either centralized, or they use blockchains, or they require money, or they require a whole network/community to exist, or they have annoying name-squatting issues, or they require a non-anonymous registration, or they save HS history on disk, or their protocol is three times more complicated than Tor itself, or ...
So it's not like we have the perfect solution on the naming scheme right now. We likely need plenty of trial experimentation before we decide on one (or multiple) naming cheme becoming the official.
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.)?
While I do think we should think of nicer representation for the new addresses than base32, and we should adress that, working on a naming system sounds like an easier way out to improve onion services usability than asking people to remember random addresses (be them 16 or 52 characters-long).
Agreed that base32 is not very good as far as encoding goes.
Regardless of the naming system that we need to deploy, we should also acknowledge that we need a good address encoding scheme anyway, as not all HSes will use the naming system. This is also the case with IP addresses: many people mess with IP addresses everyday (for config files, etc.)
I recently read this paper from USENIX which is a UX study on fingerprint encodings: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presen... We might be able to learn somethign from it. For example, they found out that alphanumeric encodings (like base32) make for the worst experience when compared to other encodings (pure numeric, unrelated words, sentences, etc.).
Finally, if we acknowledge that at least some people will have to mess with the raw addresses themselves, another benefit of the addresses being small is that they are easier to verify by hand (verifying a 24 characters fingerprint, is easier than verifying a 54 characters fingerprint).
(I now plenty of people who type “riseup” in the Google search bar of their browser to access their mailbox… They don't even want to/can't remember an URL. Hardly a chance they will remember an onion address, whatever its size.)
Indeed. We need a good naming scheme if we ever hope for onion services to become widespread.
Maybe it would be worthwhile to ask the UX team for input on the topic?
I think that would be a good idea indeed.
Hi!
George Kadianakis a écrit :
Lunar lunar@torproject.org writes:
[ text/plain ] George Kadianakis:
this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal.
Taking a step back here, I believe the size of the address to be a really minor usability problem. IPv6 adressses are 128 bits long, and plenty of people in this world now access content via IPv6. It's not a usability problem because they use a naming—as opposed to addressing—scheme to learn about the appropriate IPv6 address.
That's true. Naming systems are indeed the way to go wrt UX. The future sucks if our users are supposed to use 24 (or 56) random characters as addresses.
That said, the current IPv6 naming scheme (DNS) is far from perfect as well. Tor would never use it (or any other system with similar threat model).
Furthermore, all the _secure naming systems_ that have been suggested have their own tradeoffs. They are either centralized, or they use blockchains, or they require money, or they require a whole network/community to exist, or they have annoying name-squatting issues, or they require a non-anonymous registration, or they save HS history on disk, or their protocol is three times more complicated than Tor itself, or ...
After some discussions, I started to write the specifications of a naming service. It is based on Reed-Solomon[0] - shards are distributed over multiple nodes (which are HS to) and then signed. Thus, there is no node which has the complete registrations information. To recover the entire list of HS, multiple nodes have to be compromised or brute forced. Shards are replicated which helps to prevent a DoS. Furthermore, registrations are anonymous and volatile - the HS registers itself, a registration has to be refreshed every hour or every day (the refresh period has to be well studied in order to have a reasonable traffic). Volatility allows to keep mapping tables in RAM.
Regarding the trade-offs listed above, the only one I cannot handle is the name squatting. Regarding the others, the protocol will be simple (based on Tor communication) and few nodes are required to start the service.
So it's not like we have the perfect solution on the naming scheme right now. We likely need plenty of trial experimentation before we decide on one (or multiple) naming cheme becoming the official.
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.)?
I would be happy to take part of a working group which tackles this topic.
Regarding encoding, we can even use base64, base91, etc. I wrote a stupid HS pet name generator[1] which encodes the onion address with a dictionary of real words. It generates a set of 16 words for next gen HS.
While I do think we should think of nicer representation for the new addresses than base32, and we should adress that, working on a naming system sounds like an easier way out to improve onion services usability than asking people to remember random addresses (be them 16 or 52 characters-long).
Agreed that base32 is not very good as far as encoding goes.
Regardless of the naming system that we need to deploy, we should also acknowledge that we need a good address encoding scheme anyway, as not all HSes will use the naming system. This is also the case with IP addresses: many people mess with IP addresses everyday (for config files, etc.)
I recently read this paper from USENIX which is a UX study on fingerprint encodings: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presen... We might be able to learn somethign from it. For example, they found out that alphanumeric encodings (like base32) make for the worst experience when compared to other encodings (pure numeric, unrelated words, sentences, etc.).
Finally, if we acknowledge that at least some people will have to mess with the raw addresses themselves, another benefit of the addresses being small is that they are easier to verify by hand (verifying a 24 characters fingerprint, is easier than verifying a 54 characters fingerprint).
(I now plenty of people who type “riseup” in the Google search bar of their browser to access their mailbox… They don't even want to/can't remember an URL. Hardly a chance they will remember an onion address, whatever its size.)
Indeed. We need a good naming scheme if we ever hope for onion services to become widespread.
Maybe it would be worthwhile to ask the UX team for input on the topic?
I think that would be a good idea indeed.
Cheers!
[0] https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction [1] https://gitlab.s1.0x39b.fr/lambda/onion-pet
George Kadianakis:
Lunar lunar@torproject.org writes:
[ text/plain ] George Kadianakis:
this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal.
Taking a step back here, I believe the size of the address to be a really minor usability problem. IPv6 adressses are 128 bits long, and plenty of people in this world now access content via IPv6. It's not a usability problem because they use a naming—as opposed to addressing—scheme to learn about the appropriate IPv6 address.
That's true. Naming systems are indeed the way to go wrt UX. The future sucks if our users are supposed to use 24 (or 56) random characters as addresses.
That said, the current IPv6 naming scheme (DNS) is far from perfect as well. Tor would never use it (or any other system with similar threat model).
Furthermore, all the _secure naming systems_ that have been suggested have their own tradeoffs. They are either centralized, or they use blockchains, or they require money, or they require a whole network/community to exist, or they have annoying name-squatting issues, or they require a non-anonymous registration, or they save HS history on disk, or their protocol is three times more complicated than Tor itself, or ...
So it's not like we have the perfect solution on the naming scheme right now. We likely need plenty of trial experimentation before we decide on one (or multiple) naming cheme becoming the official.
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.)?
I'd be happy to provide feedback on the Namecoin section of such a wiki page.
Cheers, -Jeremy Rand
Jeremy Rand jeremyrand@airmail.cc writes:
[ text/plain ] George Kadianakis:
Lunar lunar@torproject.org writes:
[ text/plain ] George Kadianakis:
this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal.
Taking a step back here, I believe the size of the address to be a really minor usability problem. IPv6 adressses are 128 bits long, and plenty of people in this world now access content via IPv6. It's not a usability problem because they use a naming—as opposed to addressing—scheme to learn about the appropriate IPv6 address.
That's true. Naming systems are indeed the way to go wrt UX. The future sucks if our users are supposed to use 24 (or 56) random characters as addresses.
That said, the current IPv6 naming scheme (DNS) is far from perfect as well. Tor would never use it (or any other system with similar threat model).
Furthermore, all the _secure naming systems_ that have been suggested have their own tradeoffs. They are either centralized, or they use blockchains, or they require money, or they require a whole network/community to exist, or they have annoying name-squatting issues, or they require a non-anonymous registration, or they save HS history on disk, or their protocol is three times more complicated than Tor itself, or ...
So it's not like we have the perfect solution on the naming scheme right now. We likely need plenty of trial experimentation before we decide on one (or multiple) naming cheme becoming the official.
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.)?
I'd be happy to provide feedback on the Namecoin section of such a wiki page.
Hello people interested in this topic,
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! :)
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. :)
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
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 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
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/conferenc...
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 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/conferenc...
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
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/8217c47bce76d87d056f1bab671c44...
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 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/8217c47bce76d87d056f1bab671c44...
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 confuse website infratructure that expects a user session to remain on a single service (my understanding is that non-Tor website infrastructure that has multiple servers usually expects users to remain on a single server for a while, and might mess up session cookies and similar things otherwise). However, remembering which onion service is in use could lead to fingerprinting attacks. Using Tor's stream isolation choice as input to whether it should be remembered might make sense, but it seems tricky to do safely.
5. Is it actually desirable to have failover when one of the onion services is down? In standard DNS (which Namecoin usually tries to emulate unless there's a reason not to), when multiple IP's are listed for a name, and the first one that's tried is down, the connection just fails. Failover in DNS is handled by SRV records instead (SRV records also give much better load balancing than just listing multiple addresses). Namecoin supports SRV records just fine, so ideally we would use that approach. Sadly, Firefox doesn't respect SRV records for HTTP. And since Tor handles DNS in a special way, I'm not actually certain that Tor Browser could look up SRV records even if it wanted to. (I'm not familiar enough with how Tor handles DNS to answer that.)
6. Is it actually useful to have the Onion keys sign the Namecoin name? The most damaging attacks that I can think of where this matters, involve an end user who already knows (or can reliably look up) what onion service is the correct one. For such users, I suspect that they can get better security than either Namecoin or OnioNS can provide by simply dropping the human-readable component of Zooko's Triangle, or perhaps using a bookmark-like UI. I'm sure there are probably theoretical attacks that apply to other user classes... the question is whether those attacks are actually going to happen in the real world. (I think I very briefly discussed this topic with you a couple years ago, but I don't believe we ever discussed a solution... I'm curious what your analysis of this is.)
7. If it is useful to have the Onion keys sign the Namecoin name, is there actually a need to have those sigs in the blockchain? It seems like something that arguably would be better done either as part of the Tor protocol, or as an HTTP server that runs on an unused port of the onion service, or on an unused HTTP path of an existing HTTP server on an onion service. In any of these cases, the Namecoin name could reference the method of getting that info, which is much less data to store in the blockchain, and eliminates the squatter spam nuisance attack. If that data isn't retrievable, then probably that implies that the onion service is down, in which case it's not clear that there's any benefit to the user in being able to retrieve that data from the blockchain.
It's definitely good that we're having this discussion -- bouncing ideas off people is a great way to flesh things out and make better systems.
Cheers, -Jeremy
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
On 09/27/2016 11:15 AM, Jeff Burdges wrote:
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.
I am curious, what is your issue with the subdomains? Are you referring to enumerating all subdomains, or simply being able to confirm that a particular subdomain exists? If I know that google.com exists and I am looking for Google Maps, it seems reasonable that I might try to look up maps.google.com. I wasn't able to find a practical solution against enumeration for OnioNS, but I am curious what your exact concerns are here.
On Wed, 2016-09-28 at 19:45 -0400, Jesse V wrote:
I am curious, what is your issue with the subdomains? Are you referring to enumerating all subdomains, or simply being able to confirm that a particular subdomain exists?
Yes, confirmation of subdomans can become a problem in some contexts where GNS gets discussed as a possible solution.
If I know that blabla.onion exists as a website, then it's good that I can learn that www.blabla.onion exists as a website.
If otoh I know that blabla.zkey is a GNS record representing a Bob's contact list, then it's bad that I can learn that alice.blabla.zkey exists.
Jeff
p.s. In my message, I suggested roughly : Let P = p G be a elliptic curve point so that P.onion is a hidden service with abbreviated URL x. If y is a domain name element string, then y.P.onion and y.x point to Q.onion where Q = H(s,P) * P for some hash function H mapping into the scalars. And q = H(s,P) p is the private key for that HS record. Now this Q.onion HS record could simply forward users to another HS record with a private key not controlled by p. This means the owner of x & p can make the HSDirs forward requests in a verifiable way. The downside is more HS records. This could help create a diversity of naming solutions whose TLDs (x above) are controlled by different authorities. It's not helpful if you want x to be controlled in some distributed way though. In fact, I suppose most Tor name service proposals would be distributed, giving my idea only very limited usefulness.
-
bancfc＠openmailbox.org -
George Kadianakis -
Jeff Burdges -
Jeremy Rand -
Jesse V -
Lunar -
Nick Mathewson -
Razvan Dragomirescu -
Spencer -
U+039b -
zaki＠manian.org