7 ms·

Interesting, but I can't immediately think of any real-world use cases that this solves that aren't already solved with existing technology. The docs don't real

Interesting, but I can't immediately think of any real-world use cases that this solves that aren't already solved with existing technology. The docs don't really describe anything beyond "automatic NAT traversal and end-to-end encryption with no configuration". No configuration? Not entirely true. :) What are some use cases this can be applied to?

snissn 11y ago
i haven't looked into it deeply, but it sounds like it'd be great if you wanted to build a decentralized p2p system that didn't require a centralized routing system like dns or ip. like in practice email or twitter but decentralized, and would act similarly as simple as HTTP over DNS
deftnerd 11y ago
I'm trying to place my finger on it too but I feel an itch in the back of my brain that says "This is important and can be used for the core of something really amazing" Isn't this a similar concept to Tor addresses without the onion routing being part of it?
- baby 11y ago
  in Tor servers are one IP and one public key, so yeah you can't talk to that ip if they change their public key. It's closely related. But this is because someone is giving you a table of that ip <-> public key association. If an attacker change the public key of an ip in that table then... That's why OP's idea is stronger.
woah 11y ago
When trying to design a decentralized Internet platform of any kind, one always runs into the issue that if it is built on IP addresses, it will be fundamentally centralized. This fixes that at a low level.
- peterwwillis 11y ago
  First of all, No, a protocol or application is not fundamentally centralized because it uses IP. IP already supports multiple forms of addressing and routing and both centralized and decentralized services use IP. Second, snow does not change whether an application is centralized or not. It's the application which is centralized, not the address. Your host's address can be "1.2.3.4" or "abcdefghijklmnop", this does not change how the application works at all. Third, snow is just a tunnel. Any tunnel would "fix" an application the same way by simply translating addresses and encapsulating communication. This is basically just onion routing, but snow doesn't really exist to be an onion router. The real purpose of snow appears to be that the author wanted to use the features of IPv6 (secure connections and the ability to address and connect to a host behind a network firewall) without having to actually use IPv6 in his application, and doing all this on top of an IPv6-only network. This is what sets it apart from every other NAT-tunnel. The public key stuff is a red herring.
  - DanielDent 11y ago
    IP - and especially IPv4 - is a challenging protocol for decentralized networking. The protocol is really more suitable for a local network within a single routing and administration realm. That does not reflect today's internet. Applications tend to assume that IP addresses are globally unique. ISPs depend a lot on each other to handle routing properly. Occasionally we see a route leak when someone screws up. Sometimes it even happens deliberately. And it's entirely possible that malicious routes are announced on a regular basis to conduct clandestine MITM attacks. Technical solutions for automatically determining which ASNs should be allowed to announce an IP prefix remain problematic. And BCP 38 - while it helps to deal with DoS attacks and certain security issues - also breaks some very useful approaches to deploying high performance/scale applications. The internet is currently far more centralized than most people like to admit. The reality is that both DNS and IP are handled by delegation from a central authority. For instance, proof of IP address ownership remains outside the scope of the protocols. Network connectivity still remains based on trust relationships. That is fundamentally incompatible with a decentralized and ad-hoc approach to networked applications. There are many network operators who have been shown untrustworthy. The design of the internet hasn't quite caught up yet.
politician 11y ago
Off the top of my head, region-spanning container networking.
- buss 11y ago
  I had the same thought, but am curious if you've solved the following problems: Would you bake the private key into the container or set it at runtime? If you set it at runtime how will two containers in different places know who to talk to? Perhaps you generate the keys at build time and add the public keys to the partner containers, then at run time you inject the private key into the container via an env var. Now you have to securely manage and transport private keys and you've got two problems. There must be other things I'm not considering. And, of course, whatever system is running the container can step into it and read the private keys (or any malicious containers running on the host that are able to break out of the container). But we can just avoid that by saying they are our own hardware.
  - politician 11y ago
    I was thinking that you could bake a the Snow keys of a centralized set of discovery servers that also happen to provide key transport into the containers (so, basically, something like SkyDNS). The containers would generate private keys at runtime and then advertise themselves with the discovery servers.
jacquesm 11y ago
Skype killer.
the8472 11y ago
> I can't immediately think of any real-world use cases The problem with SSL is that it needs certificates. You need a domain name and a certificate if you want to run anything over SSL in a resonable manner. If address == identity then those requirements vanish because learning about the address already provides you all the information you need to establish a secure connection. It democratizes authenticated connections.
- marcosdumay 11y ago
  So, your idea is to use a DNSSEC-like key distribution without a DNSSEC-like zone signing? Not convinced. It's interesting, and it may be useful. But for securing what we currently do with IP it's useless.
  - paulmd 11y ago
    He's thinking on the level of "replacing IPs", not "replacing domain names". Such addresses would be like .onion domains - only becoming marginally human-meaningful with a significant computational expense. But since IPs aren't very human-meaningful anyway it's a step forward. You would still have the problem of name resolution. However since the address would be the public key, once you had resolved the address the identity of the other party would be assured. Assuming that an attacker cannot feasibly generate an equivalent public key, you remove key exchange+authentication as an attack surface. Key management could be a downside. If you want to update your key you have changed your address, which would look like a name-resolution poisoning attack. There are feasible ways around this but none are ideal (particularly if your key was compromised, mechanisms like signed forwarding records would become extremely hazardous). It would probably have to rely on name-resolution mechanisms similar to those used by current IP addresses.
lucb1e 11y ago
Connecting two computers. IP addresses (normal, unicast ones) like 1.2.3.4 and a9c::890 are meant to reach a computer somewhere on the Internet, through any number of routers. Routers are meant to forward IP packets until they reach their goal. Try it with your neighbor's computer, it's not going to work. Did he enable DMZ or port forwarding? Alright, that works when your neighbor is home. Now try it when your neighbor is at work. His IP address changed, so there goes the reachability. This seems like "duh, obviously," and you're right. But I just want to perform the fundamental action of connecting two computers. I personally used Tor to solve this problem: run a hidden service on one, connect to the .onion address on the other (you can configure ssh to work with .onion addresses). This public key system would solve the problem in a much better way, without going through Tor. Not that Tor is bad, it's just not meant for this. Connecting the two machines directly without thinking about the intermediary network is what I wanted.
- alistproducer2 11y ago
  im still wondering how a intermediary dns-like server is not needed to perform the public key to ip address translation?

snissn 11y ago

i haven't looked into it deeply, but it sounds like it'd be great if you wanted to build a decentralized p2p system that didn't require a centralized routing system like dns or ip. like in practice email or twitter but decentralized, and would act similarly as simple as HTTP over DNS

deftnerd 11y ago

I'm trying to place my finger on it too but I feel an itch in the back of my brain that says "This is important and can be used for the core of something really amazing" Isn't this a similar concept to Tor addresses without the onion routing being part of it?

baby 11y ago
in Tor servers are one IP and one public key, so yeah you can't talk to that ip if they change their public key. It's closely related. But this is because someone is giving you a table of that ip <-> public key association. If an attacker change the public key of an ip in that table then... That's why OP's idea is stronger.

woah 11y ago

When trying to design a decentralized Internet platform of any kind, one always runs into the issue that if it is built on IP addresses, it will be fundamentally centralized. This fixes that at a low level.

peterwwillis 11y ago
First of all, No, a protocol or application is not fundamentally centralized because it uses IP. IP already supports multiple forms of addressing and routing and both centralized and decentralized services use IP. Second, snow does not change whether an application is centralized or not. It's the application which is centralized, not the address. Your host's address can be "1.2.3.4" or "abcdefghijklmnop", this does not change how the application works at all. Third, snow is just a tunnel. Any tunnel would "fix" an application the same way by simply translating addresses and encapsulating communication. This is basically just onion routing, but snow doesn't really exist to be an onion router. The real purpose of snow appears to be that the author wanted to use the features of IPv6 (secure connections and the ability to address and connect to a host behind a network firewall) without having to actually use IPv6 in his application, and doing all this on top of an IPv6-only network. This is what sets it apart from every other NAT-tunnel. The public key stuff is a red herring.
- DanielDent 11y ago
  IP - and especially IPv4 - is a challenging protocol for decentralized networking. The protocol is really more suitable for a local network within a single routing and administration realm. That does not reflect today's internet. Applications tend to assume that IP addresses are globally unique. ISPs depend a lot on each other to handle routing properly. Occasionally we see a route leak when someone screws up. Sometimes it even happens deliberately. And it's entirely possible that malicious routes are announced on a regular basis to conduct clandestine MITM attacks. Technical solutions for automatically determining which ASNs should be allowed to announce an IP prefix remain problematic. And BCP 38 - while it helps to deal with DoS attacks and certain security issues - also breaks some very useful approaches to deploying high performance/scale applications. The internet is currently far more centralized than most people like to admit. The reality is that both DNS and IP are handled by delegation from a central authority. For instance, proof of IP address ownership remains outside the scope of the protocols. Network connectivity still remains based on trust relationships. That is fundamentally incompatible with a decentralized and ad-hoc approach to networked applications. There are many network operators who have been shown untrustworthy. The design of the internet hasn't quite caught up yet.

politician 11y ago

Off the top of my head, region-spanning container networking.

buss 11y ago
I had the same thought, but am curious if you've solved the following problems: Would you bake the private key into the container or set it at runtime? If you set it at runtime how will two containers in different places know who to talk to? Perhaps you generate the keys at build time and add the public keys to the partner containers, then at run time you inject the private key into the container via an env var. Now you have to securely manage and transport private keys and you've got two problems. There must be other things I'm not considering. And, of course, whatever system is running the container can step into it and read the private keys (or any malicious containers running on the host that are able to break out of the container). But we can just avoid that by saying they are our own hardware.
- politician 11y ago
  I was thinking that you could bake a the Snow keys of a centralized set of discovery servers that also happen to provide key transport into the containers (so, basically, something like SkyDNS). The containers would generate private keys at runtime and then advertise themselves with the discovery servers.

jacquesm 11y ago

Skype killer.

the8472 11y ago

> I can't immediately think of any real-world use cases The problem with SSL is that it needs certificates. You need a domain name and a certificate if you want to run anything over SSL in a resonable manner. If address == identity then those requirements vanish because learning about the address already provides you all the information you need to establish a secure connection. It democratizes authenticated connections.

marcosdumay 11y ago
So, your idea is to use a DNSSEC-like key distribution without a DNSSEC-like zone signing? Not convinced. It's interesting, and it may be useful. But for securing what we currently do with IP it's useless.
- paulmd 11y ago
  He's thinking on the level of "replacing IPs", not "replacing domain names". Such addresses would be like .onion domains - only becoming marginally human-meaningful with a significant computational expense. But since IPs aren't very human-meaningful anyway it's a step forward. You would still have the problem of name resolution. However since the address would be the public key, once you had resolved the address the identity of the other party would be assured. Assuming that an attacker cannot feasibly generate an equivalent public key, you remove key exchange+authentication as an attack surface. Key management could be a downside. If you want to update your key you have changed your address, which would look like a name-resolution poisoning attack. There are feasible ways around this but none are ideal (particularly if your key was compromised, mechanisms like signed forwarding records would become extremely hazardous). It would probably have to rely on name-resolution mechanisms similar to those used by current IP addresses.

lucb1e 11y ago

Connecting two computers. IP addresses (normal, unicast ones) like 1.2.3.4 and a9c::890 are meant to reach a computer somewhere on the Internet, through any number of routers. Routers are meant to forward IP packets until they reach their goal. Try it with your neighbor's computer, it's not going to work. Did he enable DMZ or port forwarding? Alright, that works when your neighbor is home. Now try it when your neighbor is at work. His IP address changed, so there goes the reachability. This seems like "duh, obviously," and you're right. But I just want to perform the fundamental action of connecting two computers. I personally used Tor to solve this problem: run a hidden service on one, connect to the .onion address on the other (you can configure ssh to work with .onion addresses). This public key system would solve the problem in a much better way, without going through Tor. Not that Tor is bad, it's just not meant for this. Connecting the two machines directly without thinking about the intermediary network is what I wanted.

alistproducer2 11y ago
im still wondering how a intermediary dns-like server is not needed to perform the public key to ip address translation?