[tor-dev] Special-use-TLD support

Tue Sep 29 02:05:35 UTC 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jeff Burdges wrote:
> Very interesting.  Yes, this sounds reasonable in the short run. In
> the longer run, there are several people with an interest in 
> externalizing Tor's DNS handling, which changes things.  I'll
> check out OnioNS and discuss this with people at the meeting.
> 

Thanks for making this proposal! I am very interested in seeing it
become a more general-purpose method for externalizing DNS handling.
I2P has supported pluggable NamingServices for a long time, and it is
trivial to add new methods. Now that Tor is considering them, I would
like to see whatever protocol is decided on standardized in some way,
so that GNS, Namecoin etc. can implement one protocol and be
interoperable with both Tor and I2P.

I include some comments below to this effect. I would expect that if
this went ahead, this spec would be split into a) a general spec for
the RPC protocol, and b) how Tor itself uses the protocol.

> 
> 
> Filename: xxx-special-use-tld-support.txt Title: Special-Use TLD 
> Support Author: Jeffrey Burdges Created: ?? 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 circuit'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 its 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 rudimentary tools to assist with (a).

This "must" would need to be generalized to "employ anonymizing
services for its own traffic" if left in the general spec. In practice
this will probably just be Tor if exit nodes are the means for
communicating with clearnet N nodes, but the spec shouldn't be
restrictive in this regard (e.g. N nodes run from Tor HSs or inside I2P)
.

> 
> 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 NameService lines. Tor
> should reject CNAME records that refer to .exit domains.
> 
> Configuration
> 
> We propose two Tor configuration options :
> 
> 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 
> 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 manor, the 
> digits 0-9, and the hyphen -, but hyphens may not appear at the 
> beginning or end of labels.
> 
> NameService rules route matching queries 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 protocol described below.  NameService rules are applied 
> only after all MapAddress rules.
> 
> There is no way to know in advance if N handles caching itself, 
> much less if it handles caching in a way suitable for Tor.
> Ideally, we should demands that N return an appropriate 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 allotted to
> standard Tor DNS queries, .onion lookups, etc.
> 
> Any text following -- is passed verbatim to the name service 
> supplier as service specific options, according to the RPC
> protocol described below.
> 
> Control Protocol
> 
> An equivalent of NameService 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
> 
"strong" -> "string"

> 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_gns
>
>
> 
record_lib.h

For host names that the external service maps to I2P servers, I2P
would ideally like the record to contain the full Destination, because
then only one lookup is required. This is not a domain name-like
value, like foo.onion or bar.b32.i2p, so the ability for the returned
record to support these kinds of return values should be considered.
If a domain name-like value is required, then I2P would need to do two
lookups - one for spam.gnu -> bar.b32.i2p, and then a second
(internal) for bar.b32.i2p -> DESTINATION. This partly also depends on
what kind of records the external service supports, but IMHO the RPC
protocol should not be limiting in this regard, given that it will
likely only be used by networks like Tor and I2P that cater to more
than IPv4 and IPv6.

> 
> Sepcial-use tLD suppliers should internally process CNAME records

"Sepcial" -> "Special"

> 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 receives 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.

It's not clear to me a) where this is useful for Tor, and b) where
this is useful in general. Can you provide an example?

> 
> 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.

One thing that the I2P NamingService impl doesn't do is recursive
lookups, because we haven't had a need for them yet (we instead have
an optional fallback system where if a lookup fails with one
configured service, it can try another one). But it wouldn't be hard
to implement, and I agree with having the RPC user handle CNAME
records instead of the external service.

str4d

> 
> 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
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWCfHfAAoJEBO17ljAn7Pg5xsP/A+6JT4/ZZ0ZIBJ3YTPefAd7
D42WCHDKc8F5u2SC3NzqlryvfmXN6INlEDHx7JzGg2j52AdjhXbzpR58U6rZS1LE
El/mzh3ZnIV8PpzfojY+SU7eQ/4cAgr8hJW3/x8rIRBlt2ZRBpWyKYPKBDtZtOzp
ptbNs7rjio28ymaPEpdyT7by9SzE6GiC4k4LGJnDxMUhk/f2EzjwpQJ7Um4pkKmV
ziV1FpUcuWbnXlz4rVs08DO/aULQs6d7He494XoA06HgFnTqXRirg3DdsxffbDDR
7UkL5DzM1IXb0yv2VXyB3DfUI4L5w5kZoDtaGsYtUoIZdtHJlrcV96eodAjp1PTJ
PpubSRZc/pC0tL5ol9FyGkDg/Gh+HWSHyVYkY+RJo7/4pSJc6lt/ruUQNvpRqYty
BpW8YtVHURRoThjkJ5SAWjXC96ET0yLpAXo3O9aFeNQt36vG33GmqdNHzA6x2vb8
yHjB7YlxtDsoj+o+O9cJ/9vPLKeeMjOhd6xFQaujFIOCxFT374R3WMUyniIEmrPv
dI86kalXyDM8HZ80Q4QVqDZkEZKSWdigp149cTMhU279CpmsIVPjAXWucXChtT6E
+u2MSFsGSN6mRZEGosJty18HBgS218IvYUI1IQbYfGM3mD6gL0+SEq8hNT/Bj500
r8yIwBccfe1IXEXdxyn7
=X7ur
-----END PGP SIGNATURE-----