[tor-dev] Special-use-TLD support

[Jeff Burdges]

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150927/e73d550c/attachment.sig>