Hi, While attending the OpenITP event in Rio this week, we've been discussing the problem of remembering popular or unpopular .onions. While things like PurpleOnion[0] exist - it's a different space and I'd at least like to make it easier.
I'm a DNSSEC cheerleader because I feel like it leaves out a lot of important privacy issues - query privacy being the most obvious problem, trust agility being the least obvious. None the less I think we can ignore the CA system and rely on DNSSEC, which is effectively a CA system with a different set of delegated trust roots. If we look at tor2web, we see that it relies on DNS *and* the CA model. I think if we have tor2web, we're in good shape and that having a similar system that is trusted by way of DNSSEC alone is also an interesting experiment. In an ideal world, we'd just have .onion. as a full TLD but until that date, I think it should be possible to build from a DNSSEC enabled tld such as .se or .br or whatever is of interest. I'm not sold on any specific tld though I generally think that since '.' is owned by a US corporation, I'd probably want the tld to be owned by a different corporation. Perhaps if something happens, they can fight it out... :) So the question is - how should this practically work? Should a user be able to dynamically register foo.petnames.tld and have it resolve to one or more .onions as CNAME that point somewhere or no where? If somewhere, where? Furthermore, should we ensure that a .onion can publish a petname somewhere, so we can do forward the reverse lookup? I think that would allow for some useful properties. In such a system, we'd be able to lookup foo.petnames.tld and receive a .onion or as many .onions as published. To make that useful, we'd need to ensure that applications using those Petnames were using those results and then interfacing storing them in some way - probably by using the petname-tool[1] plugin with Firefox. With such a plugin, we could automatically learn Petnames, cache them and then perhaps even confirm them. In theory, with DNSSEC, we'd be able to verify the signatures, to allow for DNSSEC protection of the data and of course, the .onion can assert what Petname is claims. If something doesn't forward and reverse resolve, we could ensure that they're not bound together. This is a pretty half-baked idea but my thought was that tor2web is only useful for HTTP. I'd like it to be partially useful, even for Tor enabled ssh clients or jabber clients or something I haven't thought of... All the best, Jacob [0] https://github.com/neoeinstein/purpleonion [1] https://addons.mozilla.org/en-US/firefox/addon/petname-tool/ _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
