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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Nick Mathewson <nickm@xxxxxxxxxxxxxx> 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-api.txt
>
> (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.

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev