5 ms·

The way DNS works in I2P[0] is pretty neat[1]. Nothing in this post sounds quite like it. It provides a great "default" user experience while allowing for finer

by apeace 10y ago

The way DNS works in I2P[0] is pretty neat[1]. Nothing in this post sounds quite like it. It provides a great "default" user experience while allowing for finer-grained control and tighter security if a user chooses. To summarize: - Users have a local "Address Book" which maps friendly names (e.g. forum.i2p) to I2P destination keys. - There are well-known I2P hidden services providing address book subscriptions. The default install includes a subscription that is maintained (and signed!) by the project maintainers. - The address book makes it clear where names are coming from. So if you decide to un-trust one of your existing subscriptions, you can still keep addresses you added yourself, etc. - New sites submit their name & key to popular address book services, but there is an additional trick you can use. Pass people a link like http://mysite.i2p/?i2paddresshelper=<key> http://mysite.i2p/?i2paddresshelper=<key>. This is known as a "jump" link. Your local HTTP proxy will take you to a page asking if you would like to add the name to your address book, or if you'd simply like to keep the name for this session but not save it. The whole system is easy to use while staying flexible, secure, and in the user's control. I'm curious if the Tor team has tried out I2P or considered a system like this. If it's not making sense to you from my summary, I highly encourage you to get I2P and try it out! [0] https://geti2p.net/en/ https://geti2p.net/en/ [1] https://geti2p.net/en/docs/naming https://geti2p.net/en/docs/naming

andreyf 10y ago
hate to be tinfoil-hat about this, but I2P seems sane in every way that Tor seems all-but-intentionally insecure in the face of sophisticated adversaries. this seems a good example of "fruitful surface area" for security vulns. another unrelated design decision is for Tor to reuse a single route which can be identified with relatively high accuracy via traffic analysis.
- beardog 10y ago
  I2P benefits from router's by default also being nodes (not saying Tor should do that though), meaning there's more "spread" of where the nodes are. Most Tor nodes, even if ran honestly, are generally in the same few data center companies; digital ocean, flokinet, etc. Also, its important to note that I2P's addresses (which are usually seen as something.i2p), can also be used directly in their 'hash' form like Tor, if you don't trust the jump/address book services.
AgentME 10y ago
Does that mean when a site links to "forum.i2p", then it's up to your own local address book where that actually goes? (Assuming people don't use the ?i2paddresshelper thing for literally every link, unless that is what is done.)
- phaer 10y ago
  I don't know how i2p works, but isn't that pretty much they way the "normal" net works? If you click a link to "news.ycombinator.com" in your webbrowser, it's mostly up to your local or ISPs DNS resolver where that takes you, no?
  - syrrim 10y ago
    True, but your ISP is expected to resolve domains to the same thing as everyone else, which is based on the distribution setup by ICANN/IANA/whoever. I2P has complete control over what a domain will resolve to, and can choose names based on utility to the user. There's also the factor of ease of use: even if everyone could edit their hosts file to make typing domains easier, few people know about the hosts file, or would think to edit it. Putting the option front and center, with a easy-to-use GUI makes a difference.
- apeace 10y ago
  That is correct. And no, people don't use jump links everywhere--only if their site is new and they are passing the links to folks on IRC, etc. Another thing I forgot to mention: if a name is unknown, your local HTTP proxy will ask you if you want to try to lookup the name from one of several popular "jump services", which are the same services providing address book subscriptions. This is where jump links come from most of the time.
im3w1l 10y ago
> The default install includes a subscription that is maintained (and signed!) by the project maintainers. This sounds like a legal risk the maintainers need to be careful with.
nikcub 10y ago
It's similar to what ideas 2.1 and 2.2 are in the blog post - a local directory that is maintained and authenticated centrally and then distributed to browsers that perform a central lookup. The downsides are that it is too centralized - it isn't difficult to imagine that a government agency would want to sinkhole silkroad.tor from the default registry. With an alternate registry, you have the balance between knowing enough about the directory provider so that you can trust them, but not enough known about then where they are open to legal recourse. ie. i'd trust a registry from riseup or duckduckgo, but that same registry is likely going to be the target of legal and hacking attempts. Likewise any provider who is sufficiently protected from those threats likely isn't well-known enough to be trustworthy. One of the benefits of the existing names is that they also authenticate the site (assuming you check it correctly, usually out of band from a trusted source like a directory or search engine) - this part can be replaced with certificates and an issuance model that can be identical to what LetsEncrypt does In terms of hosting the directory - that almost has to be decentralized using a p2p network. Similar to namecoin. Namecoin also solves the issue of distributing names and typosquatting - and it could be adapted to auction names.
- belorn 10y ago
  The problem of attaining trust from within anonymity is a interesting one, but the simple solution sounds to be to just have the directory servers make a consensus over what registry should be used as default. The tor network already depend on the directory servers, and if the registry ever get compromised the directory operators can always change the consensus. If a single directory operator get legal problems, the other operators consensus will override any recourse that may happen.
- apeace 10y ago
  > It's similar to what ideas 2.1 and 2.2 are in the blog post - a local directory that is maintained and authenticated centrally and then distributed to browsers that perform a central lookup. The downsides are that it is too centralized... It is only centralized for users with the default install, who never go into their address book. I think the real achievement of I2P's name system is that _they have made it easy for users to understand_, and the tight integration in the UX is the main differentiator I see between I2P's approach and any of the approaches in this blog post. While I think Namecoin sounds cool and all, I really hope Tor considers a simpler approach. I think it's a mistake for us to make this into a technical problem, when it's a UX problem. We're never going to get 100% secure names in a trustless environment, so why not focus on making the default pretty secure, and making the system understandable and useable?

by apeace 10y ago

andreyf 10y ago

hate to be tinfoil-hat about this, but I2P seems sane in every way that Tor seems all-but-intentionally insecure in the face of sophisticated adversaries. this seems a good example of "fruitful surface area" for security vulns. another unrelated design decision is for Tor to reuse a single route which can be identified with relatively high accuracy via traffic analysis.

beardog 10y ago
I2P benefits from router's by default also being nodes (not saying Tor should do that though), meaning there's more "spread" of where the nodes are. Most Tor nodes, even if ran honestly, are generally in the same few data center companies; digital ocean, flokinet, etc. Also, its important to note that I2P's addresses (which are usually seen as something.i2p), can also be used directly in their 'hash' form like Tor, if you don't trust the jump/address book services.

AgentME 10y ago

Does that mean when a site links to "forum.i2p", then it's up to your own local address book where that actually goes? (Assuming people don't use the ?i2paddresshelper thing for literally every link, unless that is what is done.)

phaer 10y ago
I don't know how i2p works, but isn't that pretty much they way the "normal" net works? If you click a link to "news.ycombinator.com" in your webbrowser, it's mostly up to your local or ISPs DNS resolver where that takes you, no?
- syrrim 10y ago
  True, but your ISP is expected to resolve domains to the same thing as everyone else, which is based on the distribution setup by ICANN/IANA/whoever. I2P has complete control over what a domain will resolve to, and can choose names based on utility to the user. There's also the factor of ease of use: even if everyone could edit their hosts file to make typing domains easier, few people know about the hosts file, or would think to edit it. Putting the option front and center, with a easy-to-use GUI makes a difference.
apeace 10y ago
That is correct. And no, people don't use jump links everywhere--only if their site is new and they are passing the links to folks on IRC, etc. Another thing I forgot to mention: if a name is unknown, your local HTTP proxy will ask you if you want to try to lookup the name from one of several popular "jump services", which are the same services providing address book subscriptions. This is where jump links come from most of the time.

im3w1l 10y ago

> The default install includes a subscription that is maintained (and signed!) by the project maintainers. This sounds like a legal risk the maintainers need to be careful with.

nikcub 10y ago

It's similar to what ideas 2.1 and 2.2 are in the blog post - a local directory that is maintained and authenticated centrally and then distributed to browsers that perform a central lookup. The downsides are that it is too centralized - it isn't difficult to imagine that a government agency would want to sinkhole silkroad.tor from the default registry. With an alternate registry, you have the balance between knowing enough about the directory provider so that you can trust them, but not enough known about then where they are open to legal recourse. ie. i'd trust a registry from riseup or duckduckgo, but that same registry is likely going to be the target of legal and hacking attempts. Likewise any provider who is sufficiently protected from those threats likely isn't well-known enough to be trustworthy. One of the benefits of the existing names is that they also authenticate the site (assuming you check it correctly, usually out of band from a trusted source like a directory or search engine) - this part can be replaced with certificates and an issuance model that can be identical to what LetsEncrypt does In terms of hosting the directory - that almost has to be decentralized using a p2p network. Similar to namecoin. Namecoin also solves the issue of distributing names and typosquatting - and it could be adapted to auction names.

belorn 10y ago
The problem of attaining trust from within anonymity is a interesting one, but the simple solution sounds to be to just have the directory servers make a consensus over what registry should be used as default. The tor network already depend on the directory servers, and if the registry ever get compromised the directory operators can always change the consensus. If a single directory operator get legal problems, the other operators consensus will override any recourse that may happen.
apeace 10y ago
> It's similar to what ideas 2.1 and 2.2 are in the blog post - a local directory that is maintained and authenticated centrally and then distributed to browsers that perform a central lookup. The downsides are that it is too centralized... It is only centralized for users with the default install, who never go into their address book. I think the real achievement of I2P's name system is that _they have made it easy for users to understand_, and the tight integration in the UX is the main differentiator I see between I2P's approach and any of the approaches in this blog post. While I think Namecoin sounds cool and all, I really hope Tor considers a simpler approach. I think it's a mistake for us to make this into a technical problem, when it's a UX problem. We're never going to get 100% secure names in a trustless environment, so why not focus on making the default pretty secure, and making the system understandable and useable?