Re: [tor-dev] Special-use-TLD support

[Jeff Burdges]

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

signature.asc
Description: This is a digitally signed message part
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Tim Wilson-Brown - teor]

> On 29 Sep 2015, at 09:39, Jeff Burdges  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Christian Grothoff]

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.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeff Burdges]

On Tue, 2015-09-29 at 00:59 +, 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



signature.asc
Description: This is a digitally signed message part
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/29/2015 07:39 AM, Jeff Burdges wrote:
> On Tue, 2015-09-29 at 00:59 +, 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 SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWCrI8AAoJEAHN/EbZ1y06e4AP/R/yJ11lHVl6L4ardFkBeUEf
yztAUkX8TWGLBTufsedA9HpF6nxfysGXAZx1HttTrdACspxF533Zzxh8lU+sN0Ak
iprJlcqkgPdxrt9XWzgLcLbk1Sie1mjAQDuPYQTFg9KEin4JuCO71JpPVhJBIr4f
8rO6tvo6XQytwEVopdxpuiJ/ZavpVWzcM2iFucD6sfpVEPGLPBAyaIxygpVI6/+Y
MzV9krQJZChCr/dUiIzM8eVDe0IzgB7QOxvGK2R4VR1PVY35sfnVJu6gS+P11R/A
QkF96auYDQ/zzuBLrrYpW0xkvxbqqSyOdWSzSuv5qP61uRNWe5l3yG4Zagx1aB+q
hvU2P8Nlz0ZKGSwqt0zk+W70DaagOsaR9swzxKKCGtl2+tXkNmbHRzsbJN/PWKP1
liXBV57uxNVg7sfbxISrg2JRCclsMWqqyAYidJBdDCxzW4FE+VmIXU5iBwbiklWr
Ge3iDdgxomuw1F4ZHs3FjC/p7rWPhQOS12Y9mM9tYyISUSzqA10ANod7TGLbMTie
xDR0zrl5vDN/8B8RJSzPsOuHApTs98tzEn6pBjj90Z0yMKDlUyLcXRTtcIIDbS9q
vwyTPGUdxkuJW23DD8EuMTl0b3ulvCivirfZyujoCk4GyFQK6CAETfcnyDa4OIHK
cfjHcgazm+Izv5eI/1bx
=n6Jn
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[str4d]

-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 [.]  [noncannonical] [timeout=num]
> [-- service specific options]
> 
> We require that  be either the path to a UNIX domain 
> socket or an address of the form IP:port.  We also require that 
> each  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  then a query is sent to the  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 

Re: [tor-dev] Special-use-TLD support

[Jeff Burdges]

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

signature.asc
Description: This is a digitally signed message part
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[hellekin]

-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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJWCYfTXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9J9QP/10SdTVt6PqeB1G8J21RSNwO
MtldIm0qtSCKB0j8KTSb9OxM2s3kK3PrQCSVH7q10I5OGCPEHL7GKqkbH8KRcO7A
K9dQYBeAaVqmshHu8Qp6DpXeN4r6UBDFv980xJZJGRGGY6bP5nvo5ulD9ZkWyug6
LJB+/aEk1pcKO9f4bve9NeEiW09PWfIP8Et+nkO3Rp53nh5h3ZdbHfVPWECmXA8L
stNFkXQa78yjF/tdfUzi9WRxErs4Sp5uMwk76iCYnaW+vkzfIouKRJt4DjCXRcj3
hROtNkiB9ZY+LeRrxNoALRQFT4GHByOSwUeRKEiIq2lfDYLiC7s+pMeBXaY8TNlA
mRLOvGYlKnAHFN5jql6wZYvpcgPgFZAR/auN34VlCSHR8FDUTBNo+TQWd50oS/1y
1dWsXnRkU943a/PRwybvo15hkec8UDMgY71ToMLT+SySJQHDfnHyMni8kSU0Caqw
n8IDsfsXH+fYe+gb8ft6L7STsplKDc3p7EN1qJXTBtnxngt85zZ7t1X+5MFk3KOI
YHd5cDZT2MwHIxDqTkPHcHsiiZNSw6mGF7YiJFZtDK5Bnmcmtbswq2TesXoofrMp
B7yZXDSZBmPJ5MGhuSo/JnjzuRJzXe2Gzhkz9DsglGx/LFJ7Y1e0RhcBbOp4Shal
MLLgY/2iVV4RwBl5lwSx
=XpKw
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeff Burdges]

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


signature.asc
Description: This is a digitally signed message part
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Roger Dingledine]

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

Re: [tor-dev] Special-use-TLD support

[Tim Wilson-Brown - teor]

> On 28 Sep 2015, at 15:20, Jeff Burdges  wrote:
> 
>> 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.

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 


Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/28/2015 01:34 PM, Jeff Burdges wrote:
> On Sun, 2015-09-27 at 22:31 +, 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWCeJpAAoJEAHN/EbZ1y06h8oQAJGATJdiWg12mcRsZJ8RQeUX
mkTw+CYRMqptqt1J2PjG2g0nTIRyrwmG/coufMhPNMJBfiOKRxNvnSO/QxotUZmx
0xqzTHoaWOvNokjkGumg2J44RRFtFMPZp4/W0fpAIX820ch13f4C0RTt1qH4Asxd
PFlt/LXlVtaBHthBeAh8GNfPOmQJG0hPxLg0pP8sD2CrfvXk1VaW+dyHAvqJrPcG
CjYcgKsnzYX/FG558Kd7tfCosV95GQujMUY1AUkS7WZjU/vDXFnjZPkGjnBBOWwB
vWEYCrLMmkJWBFyTaJvdy5M39+RiXB29YlMvwOb/+dZ5QhsutU/43cP2Bi4lEqay
5ozNpDQdKEZt5Zzxs75Uad5+zEuvSg05OUEHAMgWjZQWnObnCvskWS+G2cIsgyKE
LkwntN2Njpn6UmSTQpVhakEWIcQ4n8qX6jZyw9mLxGuA4Vjlxptv40J64VvDjLri
eyokAEFO8kYtGD+3tRfj/bUjJ94q2Fb23M9Wtp93KwbhUkc6ZlZmCWtAYzNhev9e
ByjQhTcj0Y29VkS735ey0ux89FqewXR756crC63a7S2sLsU4mT8CjVcQCc+RGhbD
lcv0CbSe8zo4+RrS1yWCaPZu1sLEVKFs1m4629/zZqtusUONLNs064sfmKCa5ZZA
IAu2MwkFBJqsBi1m35nU
=WrEQ
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeff Burdges]

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


signature.asc
Description: This is a digitally signed message part
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeff Burdges]

On Sun, 2015-09-27 at 22:31 +, 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




signature.asc
Description: This is a digitally signed message part
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeff Burdges]

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

signature.asc
Description: This is a digitally signed message part
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Sebastian G.]

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.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeremy Rand]

-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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWCG5QAAoJEAHN/EbZ1y06+SMQAJhN8evB2zHBqOHV8BGzQDPc
Rcwh2BXS5GDGMVoFxfTl7vyEcXf6jlHxHccbVsPihk+v5P3krDSvFggviW/+i9SU
OVg7GItivBF+QGkfe4vsmIx873/1DqNBomX6cbyisM2avLAFxOWMBHBC+Bs9dOsc
+0jT3yn7Uns0+IY8LuzgjbRVnlSrSIx7GuM8uq3fb+9OrdC/ZVgY64J4wTjFTvdi
ulrMRmQryzSC8VQ3eqqGoc0X8AytSYH54WHxwVa6gxp3tfxZ6dqfKivBUeOWpci7
+Q+q77W87GDM1VO14iRyOp69krC5RqF+vrGYlYhwmRUlpasDy+M85qigkUN0YgyP
/vVQiugkPPIyZa2QxuGrlfQ/doo1VwjY+HV0JFVkFW9tZnUsk79nhEx6R61I/AbE
KO2ttRZaWxtjPnjostVEzePywfNGKPEcq+4iRL24eY/upVRXd0wB2/99FnMhqjVG
8qk8G/Qi0EtvcgHsrxcOG44hUMv1stoHywbqcfChdKodomQMAJbPeUQ/xd9V83h4
0d1fe/Hov7MGQ0o2X007/Y9YbVfAlxjdgLSfb0qPDP/ini7jhXIixbX0raBZ5H2U
CbLrqTvf5PRWzd6lJb8wbpyo9QC1sWsR6uuqGDKypPy7d6NH8odTjAc/yXG5r7gp
YvGdrSpP45Bpp9rPZFJL
=Q21Y
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Tom van der Woerdt]

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