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)
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev