[tor-dev] Proposal 274: A Name System API for Tor Onion Services

[Jeremy Rand]

Hi George,

Here are my comments:

2.3.1

> If there are multiple name plugins that correspond to the requested
> address, Tor queries all relevant plugins sorted by their priority
> value, until one of them returns a successful result.

It's unclear whether the sort operation referred to here is ascending or
descending.

> If all plugins fail to successfuly perform the name resolution, Tor
> SHOULD default to using the exit node for name resolution.
> XXX or not?  because of leaks?

I would strongly recommend not using exit relays to resolve Namecoin
domains.  I recommend that if a locally specified Namecoin instance
fails to resolve a Namecoin domain, then the user should receive an
error, either stating that the domain doesn't exist, or that Namecoin
encountered a problem (depending on which is the case).

2.5.1

> where QUERY_ID is a unique integer corresponding to this query, and
> NAME_STRING is the name to be queried.

Some Namecoin resolution modes (in particular headers-only SPV clients)
will generate network traffic on lookups.  I therefore recommend that
sufficient information be passed in the RESOLVE line to allow the
Namecoin lookup network traffic for different requests to be
stream-isolated in the same way that the connections to the resulting
addresses would be stream-isolated.  (This is the same concern as
Arthur's feedback.)

> where QUERY_ID is the corresponding query ID and STATUS_CODE is an
> integer status code. RESULT is the resolution result (an onion
> address) or an error message if the resolution was not succesful.

Namecoin domain names can point to IP addresses and CNAMEs to
ICANN-based DNS names in addition to onion service addresses.  It is my
opinion that Namecoin domains that point to IP addresses and ICANN-based
DNS names are useful for Tor users, since they are resistant to some
censorship attacks (e.g. domain takedowns) and MITM attacks (because the
TLS fingerprint is obtained from the blockchain rather than trusting a
CA).  As such, I recommend that this message format be modified to allow
a name plugin to return an IP address or ICANN-based DNS name as an
alternative to an onion service address.

Open question: is it useful to allow multiple onion services addresses
or multiple IP addresses to be returned, for purposes of load balancing
or failover?  Letting Tor handle the selection of which address to pick
from the list might make stream isolation related issues easier to
handle safely.

2.5.3

> XXX NAME_RESOLUTION_TIMEOUT = ???

As one data point, the near-worst-case Namecoin lookup time I measured
in testing for the slowest lookup mode in my SPV client was between 2
and 3 seconds (over clearnet).  I don't know how much slower it would be
when routed over Tor.  Most queries are much faster than this worst-case
time, and I intend to attempt to optimize this.

> XXX should we also accept IPs and regular domain results???

Yes, I recommend this for the reasons listed in my 2.5.1 feedback.

> XXX perhaps we should make sure that results are not names that need
>     additional name resolution to avoid endless loops. e.g. imagine
>     some sort of loop like this:
>      debian.zkey -> debian-bla.zkey -> debian.zkey -> etc.

Open question: is it beneficial (for example) for a Namecoin name to
point to an OnioNS name?

2.6

> Tor might need to cancel an ongoing name resolution request
> (e.g. because a timeout passed, or the client is not interested in
> that address anymore). In this case, Tor sends the following line to
> the plugin stdout as follows:

I'm curious what the intended use case is for this.  In the case of
Namecoin, I'm guessing it's probably harmless to just let the request
time out on Namecoin's end.  Is there a reason this matters for other
naming systems (which I'm less familiar with) more than Namecoin?

3.1

> People have suggested that users should try to connect to
> reddit.zkey.onion instead of reddit.zkey. That is, we should always
> preserve .onion as the tld, and only utilize second-level domains for
> naming.

Since a Namecoin domain can point to IP addresses and ICANN-based DNS
names in addition to onion service names, and a Namecoin domain owner
might wish to switch between these configurations without causing
downtime or forcing their users to change behavior, I recommend against
this.  However, see the open question below:

Open question: If a Namecoin domain points to an onion service, end
users might expect encryption to be built in, and this assumption will
be violated if the Namecoin domain switches to using an IP address.
However, Namecoin domains can include TLS fingerprints, which would be
enforced for both the IP address and the onion service address.  Is it
sufficient to tell users that TLS is required if they want encryption
for Namecoin-addressed services, or is some additional mechanism needed
here to avoid bad things?

3.4

> Does it make sense to support reverse queries, from .onion to names?
> So that people auto-learn the names of the onions they use?

After the discussion with Jesse on this mailing list earlier about this
topic, I'm actually starting to think that in Namecoin's case, it may be
problematic to expect the naming system to do reverse resolution.
(There are hacks that I discussed in that thread that could do it, but
they're unclean, spammable, and add blockchain bloat.)  My take is that
it may make more sense for this lookup to be done by the onion service
itself.  Whether this should be done by the Tor onion service protocol
itself, an extra TCP port listening on the onion service, an HTTP header
sent by the onion service, or some other mechanism is an open question.

A.2

> g) Namecoin/Blockstart

I'm not sure what Blockstart is; is that intended to be Blockstack?

Cheers,
-Jeremy Rand
(Lead Application Engineer at Namecoin)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161008/a710c993/attachment.sig>