Hey Jeff, Definitely very interesting and it's nice to see namecoin and friends in the Tor context.
Questions : * are those directives handled on the relay or the client? If relay, how will the client know which node to talk to? * please don't add support for .exit here, external parties should never be able to lead users to that (and having cnames point at them would break that) * what happens if two directives compete for the same TLD? Especially if these are handled at the relay... Tom > On 27 Sep 2015, at 19:47, Jeff Burdges <[email protected]> wrote: > > > This is the first of two torspec proposals to help Tor work with Sepcial-Use > TLDs, like the GNU Name system or NameCoin. The second part will be an > anycast facility. - Jeff > > > > > > Filename: xxx-special-use-tld-support.txt > Title: Special-Use TLD Support > Author: Jeffrey Burdges > Created: 20 Sept 2015 > Status: Draft > Implemented-In: ? > > Abstract > > Suppose Special-Use TLDs in Tor via external Domain Name System (DNS) > suppliers, such as the GNU Name System and NameCoin. > > Background > > Special-use TLD supplier software integrates with the host operating > system's DNS layer so that other software resolves the special-use TLD > identically to standard DNS TLDs. On Linux for example, a Special-Use > TLD package could create a plugin for the Name Service Switch (NSS) > subsystem of the GNU C Library. > > Tor cannot safely use the local system's own DNS for name resolution, > as doing so risks deanonmizing a user through their DNS queries. > Instead Tor does DNS resolution at a circut's exit relay. It follows > that Tor users cannot currently use special-use TLDs packages in a safe > manor. > > In addition, there are projects to add public key material to DNS, like > TLSA records and DNSSEC, that necessarily go beyond NSS. > > Design > > We denote by N an abstract name service supplier package. > There are two steps required to integrate N safely with Tor : > > Of course, N must be modified so as to (a) employ Tor for it's own > traffic and (b) to use Tor in a safe way. We deem this step outside > the scope of the present document since it concerns modifications to N > that depend upon N's design. We caution however that peer-to-peer > technologies are famous for sharing unwanted information and producing > excessively distinctive traffic profiles, making (b) problematic. > Another proposal seeks to provide rudementary tools to asist with (a). > > We shall instead focus on modifying Tor to route some-but-not-all DNS > queries to N. For this, we propose a NameService configuration option > that tells Tor where to obtain the DNS record lying under some specific > TLD. > > Anytime Tor resolves a DNS name ending in an Special-Use TLD appearing > in an NameService configuration line then Tor makes an RPC request for > the name record using given UNIX domain socket or address and port. > > We should allow CNAME records to refer to .onion domains, and to > regular DNS names, but care must be taken in handling CNAME records > that refer to Special-Use TLDs handled by NameSerice lines. > Tor should reject CNAME records that refer to the .exit domains. > > Configuration > > We propose two Tor configuration options : > > NameSubstitution [.]source_dnspath [.]target_dnspath > NameService [.]dnspath socketspec > [noncannonical] [timeout=num] > [-- service specific options] > > We require that socketspec be either the path to a UNIX domain socket > or an address of the form IP:port. We also require that that each > *dnspath be a string conforming to RFC 952 and RFC 1123 sec. 2.1. > In other words, a dnsspec consists of a series of labels separated by > periods . with each label of up to 63 characters consisting of the > letters a-z in a case insensitive mannor, the digits 0-9, and the > hyphen -, but hyphens may not appear at the beginning or end of labels. > > NameSubstitution rules are applied only to DNS query strings provided > by the user, not CNAME results. If a trailing substring of a query > matches source_dnspath then it is replaced by target_dnspath. > > NameService rules route matching query to to appropriate name service > supplier software. If a trailing substring of a query matches dnspath, > then a query is sent to the socketspec using the RPC protcol descrived > below. Of course, NameService rules are applied only after all the > NameSubstitution rules. > > There is no way to know in advance if N handles cahcing itself, much > less if it handles caching in a way suitable for Tor. > Ideally, we should demands that N return an approporaite expiration > time, which Tor can respect without harming safety or performance. > If this proves problematic, then configuration options could be added > to adjust Tor's caching behavior. > > Seconds is the unit for the timeout option, which defaults to 60 and > applies only to the name service supplier lookup. Tor DNS queries, > or attempts to contact .onion addresses, that result from CNAME records > should be given the full timeout alloted to standard Tor DNS queries, > .onion lookups, etc. > > Any text following -- is passed verbatim to the name service suppllier > as service specific options, according to the RPC protocol described > below. > > Control Protocol > > An equivalent of NameService and NameSubstitution should be added to > the Tor control protocol, so that multiple users using the same Tor > daemon can have different name resolution rules. > > RPC protocol > > We require an RPC format that communicates two values, > first any service specific options give on the NameService line, and > second the query name itself of course. > We might however discuss if there are any standardized flags, distinct > from these options, and whether they should be communicated separately. > > In principle, Tor could make due with simply receiving a strong in > return. We recommend however that Tor expect a return format as or > more powerful than full DNS queries. In particular, we should endever > to return TLSA records at the same time as the underlying DNS record, > so that Tor Browser can utilize that key material. The GNS Record > format used by the GNU Name System addresses this and other issues, so > it should be taken as a candidate. See : > > https://github.com/GNUnet/gnunet/blob/gnunet/src/include/gnunet_gnsrecord_lib.h > > Sepcial-use tLD suppliers should internally process CNAME records that > fall into their own domains, but they should return CNAME records to > Tor that refer to .onion or .exit domains, or to normal DNS names. > Initially, Tor should issue an error if it recieves a CNAME record that > matches an NameService line. If however that NameService line contains > the noncannonical option, then CNAME records should instead bypass it, > and use Tor's DNS system. > > At present, alternative DNS packages should not pass CNAME records > between themselves, despite speaking the same RPC protocol, as this > creates unknown risks. As such forwarding can be done most safely by > Tor itself, the Tor Project reserves the right to forward CNAME records > between NameService lines in the future. Applications should therefore > not depend upon the above error being returned. > > Variations > > Tor would conceivably benefit from externalizing its own DNS handling > as a separate process. This might however require that Tor have the > ability to start name service suppliers. A fuller consideration of > this might alter our design of the NameService configuration option. > > Acknowledgments > > Based on extensive discussions with Christian Grothoff and George > Kadianakis. > > > > _______________________________________________ > tor-dev mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
