[tor-dev] Comments on proposal 279 (Name API)

[Nick Mathewson]

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-api.txt

(Some of  these are probably things you already meant, or already said
elsewhere.)



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 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.

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".)


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".)

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.

Section 2.5.1:

Is the algorithm allowed to produce non-onion addresses?  Should it be?

Must query IDs be unique?  Over what scope must they be unique? Who
enforces that?

May query IDs be negative?  Can they be arbitrarily large?

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.

Section 2.5.3.

See security notes on caching below; client-side caching can lead to
undesirable results.

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.



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.)


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?

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.