Nick Mathewson nickm@torproject.org writes:
Hi ! I'll make some comments here on the draft onion naming API at
https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-ap...
(Some of these are probably things you already meant, or already said elsewhere.)
Thanks for the timely comments! I'm replying to this thread with my thoughts, but I didn't have time to actually fix the proposal. I'll do that in The Future.
Section 2.1 and elsewhere:
I suggest that we require all address suffixes to end with .onion; other TLDs are not reserved like .onion is, and maybe we shouldn't squat any we haven't squatted already. I think we might also want to have all output addresses end with .onion too.
I suggest also that we might want to reserve part of the namespace for standardized namespaces and some for experimental or local ones. Like, if we standardize on namecoin that could be .bit.onion, but if we don't, it could be .bit.x.onion.
I have mixed feelings about keeping the .onion suffix.
One one hand it seems like The Right Thing to do, since we managed to get .onion standarized in the IETF which comes with various benefits. Also, starting to squat other tlds arbitrarily seems like a silly thing to do.
However, I also dislike asking users to visit something.bit.onion instead of something.bit, since people are not used to the second tld having a semantic meaning, and I can imagine people getting very confused about what it means.
Anyhow, it seems like maintaining the .onion suffix is the right approach here.
I finally suggest that we distinguish names that are supposed to be global from ones that aren't.
Section 2.3:
How about we require that the suffixes be distinct? If we do that, we can drop this "priority" business and we can make the system's behavior much easier to understand and explain.
Definitely agreed on this simplification suggestion. The priority feature has confused people, and it's not that useful. In the future we could reinstall it if we consider it practical.
Let's require that the TLDs actually begin with a dot. (That is, I think that ".foo.onion" can include "bar.foo.onion", but I don't like the idea of "foo.onion" including "barfoo.onion".)
Makes sense.
Section 2.3.1:
Does the algorithm apply recursively? That is, can more then one plugin rewrite the same address, or can one plugin rewrite its own output?
(I would suggest "no".)
Agreed no. We should specify it.
I think there should be a way for a plugin to say "This address definitely does not exist" and stop resolution. Otherwise no plugin can be authoritative over a TLD.
Agreed.
Section 2.5.1:
Is the algorithm allowed to produce non-onion addresses? Should it be?
I'd say no. We should specify this.
Must query IDs be unique? Over what scope must they be unique? Who enforces that?
I think the NS API client should enforce that, and maybe the server should throw an error if it's not unique.
We should specify.
May query IDs be negative? Can they be arbitrarily large?
We should specify this too.
I think result should indeed be optional on failure.
Section 2.5.1 and 2.5.2:
We should specify what exactly clients and plugins will do if they receive an unrecognized message, or a malformed message.
Agreed.
Section 2.5.3.
See security notes on caching below; client-side caching can lead to undesirable results.
Agreed.
As noted above, I agree with requiring all result addresses to be .onion.
Section 3.1:
I prefer the "put everything under .onion" option. I also think that we should require that the second-level domain be 10 characters or less, to avoid confusion with existing onion addresses.
We should think more about this, but seems reasonable.
General questions:
I know we've done stdout/stdin for communication before, but I wonder if we should consider how well it's worked for us. The portability on Windows can be kind of hard.
Two alternatives are TCP and named pipes.
Another alternative might be just using the DNS protocol and asking for some kind of "ONION_CNAME" record. (DNS is ugly, but at least it's nice and standard.)
Yup, I think this is an _important_ open part of the proposal that we should figure out sooner than later. Ideally, we should consult Nathan or mtigas or other members of our mobile team. I wish I had done this during the dev meeting...
TCP seems like a plausible alternative here. Unfortunately, we will have to invent a new protocol for that tho.
Security notes:
I'd like to know what the browser people think about the risks here of (eg) probing to see whether the user has certain extensions installed or names mapped. Maybe .hosts.onion should only be allowed in the address bar, not in HREF attributes et al?
Yep, David F. also mentioned this problem. We should think of how to address it. Browser people might have good ideas here indeed.
We might want to think about cache-related timing attacks here. Perhaps we should have a "no caching" rule.
We should probably add a security notes section for how to write plugins that aren't dangerous: a bad plugin potentially breaks user anonymity.