On Mon, 2015-09-28 at 16:26 -0400, Roger Dingledine wrote:
> On Mon, Sep 28, 2015 at 03:20:47PM +0200, Jeff Burdges wrote:
> > I proposed that Tor implement NameService rules using UNIX domain
> > sockets, or ports, since that's how GNUNet works, but maybe Tor
> > should
> > instead launch a helper application it communicates with via stdin
> > and
> > stdout. I donno if that'll work well on Windows however.
>
> If you're to be running a second program that does the "resolves",
> then
> I think you should really think about adding a third program that
> talks
> to Tor on the control port and does all of these rewrites via the
> control
> protocol without needing any further Tor modifications. (If you
> wanted,
> you could make these second and third programs be just one program.)
>
> This is I believe how Jesse's "OnioNS" tool works at present: you
> connect
> to the control port (e.g. via a Stem script), tell Tor that you want
> to
> decide what to do with each new stream (set __LeaveStreamsUnattached
> to
> 1), and then you let Tor pick (attachstream to 0) for all the streams
> except the special ones. When you see a new special stream, you do
> the
> lookup or resolve or whatever on your side, then REDIRECTSTREAM the
> stream to become the new address, then yield control of the stream
> back
> to Tor so Tor picks a circuit for it.
>
> The main downside here is that you need to run a new Tor controller.
> But
> if you're already needing to run a separate program, you should be
> all set.
>
> What am I missing?
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.
In the mean time, I updated the previous proposal based on comments
here. Also, I remove the NameSubstitution idea when I remembered
MapAddress.
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).
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
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
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 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.
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