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_li...
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.
27.09.2015, 19:47 Jeff Burdges:
Hi,
I have nothing to add, but there are a few spelling mistakes that someone might want to correct before adding it to the repository.
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
s/it's/its
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).
s/rudementary/rudimentary s/asist/assist
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.
(I wonder if .exit is still valid, also if it is 'the' .exit instead of just .exit)
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
'that' appears twice.
*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
s/mannor/manor
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
'to' appears twice, and I guess it is not correct. I fail to parse the sentence, but it might be 'matching queries' or 'a matching query'.
supplier software. If a trailing substring of a query matches dnspath, then a query is sent to the socketspec using the RPC protcol descrived
s/protcol/protocol s/descrived/described
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
s/cahcing/caching
less if it handles caching in a way suitable for Tor. Ideally, we should demands that N return an approporaite expiration
s/approporaite/appropriate
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
s/suppllier/supplier
as service specific options, according to the RPC protocol described below.
Best regards, Sebastian G.
On 27 Sep 2015, at 20:46, Sebastian G. <bastik.tor> wrote:
27.09.2015, 19:47 Jeff Burdges:
Hi,
I have nothing to add, but there are a few spelling mistakes that someone might want to correct before adding it to the repository.
...
*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
s/mannor/manor
s/mannor/manner is most likely what was intended
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Hi Jeff,
I have some questions about how NameSubstitution rules work in some edge cases:
On 27 Sep 2015, at 19:47, Jeff Burdges burdges@gnunet.org wrote: ... 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.
Are multiple NameSubstitution rules applied in the order they are listed?
For example: NameSubstitution .com .net NameSubstitution .example.net http://example.net/ .example.org
What does foo.example.com http://foo.example.com/ get transformed into?
Are trailing periods significant?
For example: NameSubstitution .com .net
What does example.com http://example.com/. get transformed into?
For example: NameSubstitution .com. .net.
What does example.com http://example.com/ get transformed into?
Are leading periods significant?
For example: NameSubstitution com net
What does example.com http://example.com/ get transformed into? What does foo.viacom get transformed into?
Are duplicate rules significant?
For example: NameSubstitution .com .com.com NameSubstitution .com .com.com
What does example.com http://example.com/ get transformed into?
Is there a length limit for the final query? (DNS names are limited to 255 characters.)
For example: NameSubstitution .a .<254 characters>
What does <253 characters>.a get transformed into?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On Sun, 2015-09-27 at 23:32 +0200, Tim Wilson-Brown - teor wrote:
I have some questions about how NameSubstitution rules work in some edge cases:
In truth, I originally wrote the NameSubstitution rules bit for the .gnu TLD. In the end, Christian explained why that doesn't work, mostly that the .gnu TLD should never query the network.
I left NameSubstitution in as a discussion point, but it wouldn't surprise me if NameSubstitution didn't quite suffice for any real purposes.
It's probably best if one instead writes a simple tool called from a NameService rule that provides NameSubstitution like functionality.
Are multiple NameSubstitution rules applied in the order they are listed?
For example: NameSubstitution .com .net NameSubstitution .example.net .example.org
What does foo.example.com get transformed into?
In principle, one could apply the most specific (longest) rule, but..
My prejudice is that disjointness should be enforced for anything in the torrc. Otherwise, one must worry more about attackers modifying torrc files.
Are trailing periods significant?
I believe they do not make sense. DNS names may not end in a period, so this is covered by the references I gave, not sure if I speced it correctly though.
Are leading periods significant?
I doubt the leading periods matter, but they make rules marginally easier to read.
Are duplicate rules significant?
No.
Is there a length limit for the final query? (DNS names are limited to 255 characters.)
For example: NameSubstitution .a .<254 characters>
What does <253 characters>.a get transformed into?
Originally, I'd meant to propose 510 characters since I'd envisioned blahblah.gnu being translated into blahblah.hash.zkey where .zkey gets processed by GNS. There is no need for that now, so I'm ambivalent.
As I said, we should probably drop the NameSubstitution rules in favor of an external application that one calls via a NameService rule, but this brings up a larger question :
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.
Jeff
On 28 Sep 2015, at 15:20, Jeff Burdges burdges@gnunet.org wrote:
Are multiple NameSubstitution rules applied in the order they are listed?
For example: NameSubstitution .com .net NameSubstitution .example.net http://example.net/ .example.org http://example.org/
What does foo.example.com http://foo.example.com/ get transformed into?
In principle, one could apply the most specific (longest) rule, but..
My prejudice is that disjointness should be enforced for anything in the torrc. Otherwise, one must worry more about attackers modifying torrc files.
I don’t believe this is part of our standard threat models - torrc files are generally trusted.
Are trailing periods significant?
I believe they do not make sense. DNS names may not end in a period, so this is covered by the references I gave, not sure if I speced it correctly though.
Fully Qualified Domain Names (FQDNs) end with a period. They are a absolute domain name reference, rather than domain names without periods, which can have search domains appended by the browser or OS.
https://en.wikipedia.org/wiki/Fully_qualified_domain_name https://en.wikipedia.org/wiki/Fully_qualified_domain_name
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
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?
--Roger
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.
On 09/29/2015 12:19 AM, Jeff Burdges wrote:
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.
Also, as you see from str4d's message, there are other projects interested in having a new name resolution *API* to access Namecoin, GNS, DNSSEC etc. Thus, it makes more sense to define a new name resolution service that all of those can use, instead of a Tor-specific hack.
Just an update on this :
If anyone wants this in the short-term, then it should be done the OnioNS was, like Roger suggests.
In the longer term, there are now a handful of parties interested in building a "libnss2" that provides an asynchronous name interface to : - help resolve the disaster that arises from DNSSEC TLSA records arriving slower than the regular DNS records, - move NSS configuration into user space (DJB & other's want this), and - improve support for the capabilities of GNS and Namecoin.
If you consider what that API might look like, then you realize it's potentially not so Tor friendly : Imagine running Tor on an external device, but to do name resolution the way the user wants tor must talk to nss daemon on the user's machine, but that daemon must understand that tor requests should only go over tor. Ick!
So rather than a proposal for Tor, what we need to do is write an API proposal for a local name resolution system that solves the issues with DNSSEC, and does other things, and does not cause problems for Tor users.
Oh, there is already some asynchronous DNS library in the GNU world, but it's probably not what anyone wants.
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?
--Roger
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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@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_li...
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Mon, 2015-09-28 at 00:05 +0200, Tom van der Woerdt wrote:
Questions :
- are those directives handled on the relay or the client? If relay,
how will the client know which node to talk to?
They route name resolution requests on the client to another piece of software on the client. That piece of software is responsible for using Tor correctly, usually by being a thin shim that contacts a real client running on a volunteer exit node.
- 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)
Yes .exit is banned from CNAME records for exactly this reason.
- what happens if two directives compete for the same TLD?
Especially if these are handled at the relay...
NameService lines should explicitly specify the TLDs to which they refer. If Namecon wants to manage .coin but the torrc only gives it .bit then it only gets .bit.
Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/27/2015 05:47 PM, Jeff Burdges 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
Hi Jeff,
Thanks for working on this; Namecoin is definitely interested in this effort. I have one comment. SPV-based Namecoin clients will, under some circumstances, generate network traffic to other Namecoin P2P nodes containing names being looked up. To avoid linkability, stream isolation should be used so that different Namecoin lookups go over different Tor circuits if the lookups correspond to TCP streams that go over different Tor circuits. (Also, the choice of Namecoin nodes to peer with should be different for each identity.) Therefore, it seems to me that there should be a mechanism for Tor to provide stream isolation information to the naming systems that it calls, along with "new identity" commands.
The above issue doesn't affect full Namecoin clients, or SPV Namecoin clients that download the full unspent domain name set. I don't know enough about the GNU Name System to know how this issue affects it, if at all.
Thoughts on this?
Also, trivial spelling nitpick: "Namecoin" is typically spelled with a lowercase "c", like "Bitcoin".
Thanks again for working on this!
Cheers, - -Jeremy Rand
On Sun, 2015-09-27 at 22:31 +0000, Jeremy Rand wrote:
On 09/27/2015 05:47 PM, Jeff Burdges 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
Hi Jeff,
Thanks for working on this; Namecoin is definitely interested in this effort. I have one comment. SPV-based Namecoin clients will, under some circumstances, generate network traffic to other Namecoin P2P nodes containing names being looked up. To avoid linkability, stream isolation should be used so that different Namecoin lookups go over different Tor circuits if the lookups correspond to TCP streams that go over different Tor circuits. (Also, the choice of Namecoin nodes to peer with should be different for each identity.) Therefore, it seems to me that there should be a mechanism for Tor to provide stream isolation information to the naming systems that it calls, along with "new identity" commands.
The above issue doesn't affect full Namecoin clients, or SPV Namecoin clients that download the full unspent domain name set. I don't know enough about the GNU Name System to know how this issue affects it, if at all.
Thoughts on this?
Yes. I distrust running p2p applications not specifically designed for Tor over Tor. The GNU Name System will therefore run the DHT process on volunteer Tor exist nodes, much like how DNS queries are handled by exit nodes.
Imho, Namecoin should similarly develop a Tor Namecoin shim client that contacts special SPV Namecoin clients running on volunteer exit nodes. I'm working on a second torspec proposal that adds an AnycastExit option to simplify this.
In the long term, there are obviously concerns about bad exit nodes, especially if there are only like two exits supporting Namecoing or GNS, but currently so few people use GNS or Namecoin that we can probably ignore this.
Also, trivial spelling nitpick: "Namecoin" is typically spelled with a lowercase "c", like "Bitcoin".
Thanks!
Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/28/2015 01:34 PM, Jeff Burdges wrote:
On Sun, 2015-09-27 at 22:31 +0000, Jeremy Rand wrote:
Hi Jeff,
Thanks for working on this; Namecoin is definitely interested in this effort. I have one comment. SPV-based Namecoin clients will, under some circumstances, generate network traffic to other Namecoin P2P nodes containing names being looked up. To avoid linkability, stream isolation should be used so that different Namecoin lookups go over different Tor circuits if the lookups correspond to TCP streams that go over different Tor circuits. (Also, the choice of Namecoin nodes to peer with should be different for each identity.) Therefore, it seems to me that there should be a mechanism for Tor to provide stream isolation information to the naming systems that it calls, along with "new identity" commands.
The above issue doesn't affect full Namecoin clients, or SPV Namecoin clients that download the full unspent domain name set. I don't know enough about the GNU Name System to know how this issue affects it, if at all.
Thoughts on this?
Yes. I distrust running p2p applications not specifically designed for Tor over Tor. The GNU Name System will therefore run the DHT process on volunteer Tor exist nodes, much like how DNS queries are handled by exit nodes.
Imho, Namecoin should similarly develop a Tor Namecoin shim client that contacts special SPV Namecoin clients running on volunteer exit nodes. I'm working on a second torspec proposal that adds an AnycastExit option to simplify this.
In the long term, there are obviously concerns about bad exit nodes, especially if there are only like two exits supporting Namecoing or GNS, but currently so few people use GNS or Namecoin that we can probably ignore this.
Hi Jeff,
Do I infer correctly that the main intention of this is to decrease the possibility of attack by a Sybil attack on the Namecoin network, by making the Namecoin peer selection process have similar properties to Tor relay selection (which is relatively Sybil-resistant)? (And I guess this would also eliminate issues where a Tor client connects to a Namecoin peer who also happens to be his/her guard node.) If so, I think I cautiously agree that this may be a good idea. (I haven't carefully considered the prospect, so there may be problems introduced that I haven't thought about -- but from first glance it sounds like an improvement over what Namecoin does now, at least in this respect.)
The issue I do see is that SPV validation doesn't work well unless you ask multiple peers to make sure that you're getting the chain with the most PoW. So I gather that this would require connecting to Namecoin peers running on multiple exit nodes. I don't think that's problematic, but it would have to be taken into account.
- -Jeremy
On Tue, 2015-09-29 at 00:59 +0000, Jeremy Rand wrote:
Do I infer correctly that the main intention of this is to decrease the possibility of attack by a Sybil attack on the Namecoin network, by making the Namecoin peer selection process have similar properties to Tor relay selection (which is relatively Sybil-resistant)? (And I guess this would also eliminate issues where a Tor client connects to a Namecoin peer who also happens to be his/her guard node.) If so, I think I cautiously agree that this may be a good idea. (I haven't carefully considered the prospect, so there may be problems introduced that I haven't thought about -- but from first glance it sounds like an improvement over what Namecoin does now, at least in this respect.)
I have not thought specifically about Namecoin's threat model. If the DNS providing peer runs on the exit node then it reduces the threat model to the same threat model as DNS.
The issue I do see is that SPV validation doesn't work well unless you ask multiple peers to make sure that you're getting the chain with the most PoW. So I gather that this would require connecting to Namecoin peers running on multiple exit nodes. I don't think that's problematic, but it would have to be taken into account.
This is no different from validation for existing DNS results. Tor attempts to prevent this by building a list of bad exits, but it's challenging to catch an exit that attacks only one website.
You could check multiple peers but that costs you some anonymity. If you use many .bit names, this might expose the fact that you use Namecoin to your guard.
There are many Tor programs like Ricochet and Pond, and many websites, that should be detectable by a sufficiently dedicated guard, so that's not a compelling reason not to check multiple exits, but it requires consideration.
One could maybe design the Namecone shim to check obtain general-but -relevant information from multiple exits running the Namecoin client, but only obtain the actual result from one exit. Or maybe that's reinventing the SPV client.
Jeff
On 29 Sep 2015, at 09:39, Jeff Burdges burdges@gnunet.org wrote:
The issue I do see is that SPV validation doesn't work well unless you ask multiple peers to make sure that you're getting the chain with the most PoW. So I gather that this would require connecting to Namecoin peers running on multiple exit nodes. I don't think that's problematic, but it would have to be taken into account.
This is no different from validation for existing DNS results. Tor attempts to prevent this by building a list of bad exits, but it's challenging to catch an exit that attacks only one website.
You could check multiple peers but that costs you some anonymity. If you use many .bit names, this might expose the fact that you use Namecoin to your guard.
How do you anticipate this exposure happening? Via traffic correlation?
As far as I understand, your guard only sees your encrypted traffic, and not your exit(s) or your DNS queries.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/29/2015 07:39 AM, Jeff Burdges wrote:
On Tue, 2015-09-29 at 00:59 +0000, Jeremy Rand wrote:
The issue I do see is that SPV validation doesn't work well unless you ask multiple peers to make sure that you're getting the chain with the most PoW. So I gather that this would require connecting to Namecoin peers running on multiple exit nodes. I don't think that's problematic, but it would have to be taken into account.
This is no different from validation for existing DNS results. Tor attempts to prevent this by building a list of bad exits, but it's challenging to catch an exit that attacks only one website.
You could check multiple peers but that costs you some anonymity. If you use many .bit names, this might expose the fact that you use Namecoin to your guard.
How does checking Namecoin peers on running on multiple exits cost anonymity? I'm not quite seeing what the attack is here.
There are many Tor programs like Ricochet and Pond, and many websites, that should be detectable by a sufficiently dedicated guard, so that's not a compelling reason not to check multiple exits, but it requires consideration.
One could maybe design the Namecone shim to check obtain general-but -relevant information from multiple exits running the Namecoin client, but only obtain the actual result from one exit. Or maybe that's reinventing the SPV client.
Retrieving block headers from multiple exits, and then asking for a specific domain's SPV proof from a single exit, will at least provide reasonable assurance that the result was valid sometime in the past 8 months (expiry period for Namecoin names). Once unspent name output set commitments are added to the Namecoin block validation rules, it will provide reasonable assurance that the result was valid as of about 2 hours ago. A single node could still censor updates from the past 2 hours, which would not be the case if sufficient multiple nodes are asked.
It might also be possible to download the full blocks from the last 2 hours (along with unmined transactions) from multiple peers. This wouldn't reveal which names you're asking for, would presumably be only a few megabytes at startup (along with keeping up with incoming transactions over time), and would be sufficient when combined with SPV proofs from a single node to give you completely current data.
I'm still not seeing the attack that stems from asking multiple exits for specific domains, though. Can you elaborate?
Cheers, - -Jeremy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 09/27/2015 02:47 PM, Jeff Burdges 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
Jeff, I'd be careful using DNS (as in Ze DNS) vocabulary in specifications that are not concerned with, well, the Domain Name System. The DNS should be considered like SMTP or HTTP: its own protocol with its own rules, yada yada.
A TLD (Top-Level Domain) therefore is only TLD when it's used with the DNS root servers. You cannot talk about "alternate Domain Name Systems (DNS) providers", since DNS is unique, global, and served by the official DNS root servers. However, you can certainly mention "alternate global name systems", and choke a suit or three by being legitimately precise to the point you might be considered arrogant (but thoughtful) in doing so.
I'll wait for the next version of this draft and a bit more available time for further comments. Glad you're joining the club of polishing text to speak to genuine volunteers in making the Internet cool again. ;o)
== hk
Special-use TLDs is the official name, according to someone or other attached to DNS. I'd rate that good enough.
Afaik, there is actually no coherent name for these naming system meant to compete with DNS. Arguably, the most logical approach would be to genericize the DNS trademark and accept the resulting ambiguity, but that's not realistic. In places, I've used terms like name service, and similar, because it's largely unambiguous how Tor would use a naming scheme. I'd personally consider calling Namecoin or GNS simply "name systems" to be an exaggeration though, maybe "server name consistency system" or something. I don't think this really impacts the spec since the DNS terminology is well defined.
On Mon, 2015-09-28 at 15:32 -0300, hellekin wrote:
On 09/27/2015 02:47 PM, Jeff Burdges 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
Jeff, I'd be careful using DNS (as in Ze DNS) vocabulary in specifications that are not concerned with, well, the Domain Name System. The DNS should be considered like SMTP or HTTP: its own protocol with its own rules, yada yada.
A TLD (Top-Level Domain) therefore is only TLD when it's used with the DNS root servers. You cannot talk about "alternate Domain Name Systems (DNS) providers", since DNS is unique, global, and served by the official DNS root servers. However, you can certainly mention "alternate global name systems", and choke a suit or three by being legitimately precise to the point you might be considered arrogant (but thoughtful) in doing so.
I'll wait for the next version of this draft and a bit more available time for further comments. Glad you're joining the club of polishing text to speak to genuine volunteers in making the Internet cool again. ;o)
== hk
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sun, 2015-09-27 at 19:47 +0200, Jeff Burdges wrote: ...
Configuration
...
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.
...
I asked Yawning today if this part should (a) use a socket to a process that already exists, or (b) exec a helper program that communicates over a pipe tied to its stdio. He mentioned the PT spec does both, which I interpreted as going either way at the time. In fact, the PT spec literally requires both stdio and a socket, which sounds overly complex for this.
Anyways, if we wanted to to exec a helper program, the configuration might look something like : NameService [.]dnspath [opts ..] exec helper_prog [opts ..] We could simply speak to the helper over a pipe tied to its stdio.
Jeff
-
Christian Grothoff -
hellekin -
Jeff Burdges -
Jeremy Rand -
Roger Dingledine -
Sebastian G. <bastik.tor> -
Tim Wilson-Brown - teor -
Tom van der Woerdt