[tor-dev] Special-use-TLD support

Sun Sep 27 22:05:40 UTC 2015

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 at gnunet.org> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev