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.
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev