Re: [tor-dev] Two new Onionoo versions 2.4 and 2.5 add new "effective_family" and "measured" fields

[nusenu]

Hi,

was there a specific reason for reverting the tpo instance back to
version 2.3?
(since 2015-09-27 07:00)

thanks!





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

[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] Two new Onionoo versions 2.4 and 2.5 add new "effective_family" and "measured" fields

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/09/15 14:45, nusenu wrote:
> Hi,
> 
> was there a specific reason for reverting the tpo instance back to 
> version 2.3? (since 2015-09-27 07:00)

Oops, that's by mistake.  The host was restarted and still had 2.3
written in its crontab @reboot line.  I just changed that to 2.6.  It
might be that some documents will miss the new fields added after 2.3,
but I hope that will resolve itself over the next days.  If you're
observing any problems with this, please let me know and I'll take a look.

> thanks!

Thanks for the report!

All the best,
Karsten

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJWCGC5AAoJEJD5dJfVqbCrfsQIAJ95ND7pYmqHsMOgQyiS5A2F
R1/J357ZpA7IyzKf5bp57BiW1Dpx9u4yLzs8pVdxRjeV0xac4AYvxVQZkS8N85Bp
d0Hczzj4DfMKk8xXvxXuR9fkU+YxmmVX+VK5e6HrBPS5YHSO//HXTtdlTUWlRA6u
vpMll7GWszdY/ZJK8BGVNpY9DvEeKYfFp7JpzJ5B92r30+wwO/ut581R/uZrpQVd
jtdVwLm01tdY6fMuOsz6s7ygaHwFU5hGMDrOMSvstWH2jyRGuMtziy+F8gB46yC/
foEiW49l+KNgPJb5lqK1Vdx1sGxYTvf53ybDUHc/GxA4vszPbta95Kwu+BKbmLE=
=HA32
-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 

[tor-dev] txtorcon 0.14.0

[meejah]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm happy to announce txtorcon 0.14.0. Changes:

 * IStreamAttacher handling was missing None and DO_NOT_ATTACH cases if a 
Deferred was returned.
 * add .is_built Deferred to txtorcon.Circuit that gets callback()'d when the 
circuit becomes BUILT
 * David Stainton ported his "tor:" endpoint parser so now both client
   and server endpoints are supported. This means **any** Twisted
   program using endpoints can use Tor as a client. For example, to
   connect to txtorcon's Web site: ep =
   clientFromString("tor:timaq4ygg2iegci7.onion:80").  (In the future,
   I'd like to automatically launch Tor if required, too).
 * Python3 fixes from Isis Lovecruft (note: needs Twisted 15.4.0+)

You can download the release from PyPI or GitHub (or of course "pip
install txtorcon"):

   https://pypi.python.org/pypi/txtorcon/0.14.0
   https://github.com/meejah/txtorcon/releases/tag/v0.14.0

Releases are also available from the hidden service:

   http://timaq4ygg2iegci7.onion/txtorcon-0.14.0.tar.gz
   http://timaq4ygg2iegci7.onion/txtorcon-0.14.0.tar.gz.asc
   http://timaq4ygg2iegci7.onion/txtorcon-0.14.0-py2-none-any.whl
   http://timaq4ygg2iegci7.onion/txtorcon-0.14.0-py2-none-any.whl.asc

You can verify the sha256sum of both by running the following 4 lines
in a shell wherever you have the files downloaded:

cat