[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Special-use-TLD support
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 <burdges@xxxxxxxxxx> 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
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev