Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

2016-10-08 Thread Hugo Maxwell Connery 
Hi,

I think that this work is extremely important, and I applaud the
authors and contributors for their work.  It seems that it will also
be complicated, semantically.  What lies where, and which thing
does what?  The example recently about what is sent in the Host
header is a good example of this challenge.

I have below, in situ, made a few suggested corrections, and offered
my suggestions on a few topics.  I am not precious about my 
opinions and am happy to have them shot down by people with
a deeper understanding of the challenge at hand.

My overriding suggestion is to keep this as simple as possible in
its initial iteration.  It will almost certainly get more complex down
the line, and working out what the core principles are early on will
help guard against "feature creep".

Well done, and good luck,

  Hugo

NB: all comments prefixed with '> '
---

Filename: 274-naming-layer-api.txt
Title: A Name System API for Tor Onion Services
Author: George Kadianakis, Yawning Angel, David Goulet
Created: 04-Oct-2016
Status: Draft

  Table Of Contents:

1. Introduction
1.1. Motivation
1.2. Design overview and rationale
2. System Specification
2.1. System overview [SYSTEMOVERVIEW]
2.2. System Illustration
2.3. System configuration [TORRC]
2.3.1. Tor name resolution logic
2.4. Name system initialization [INITPROTOCOL]
2.5. Name resolution using NS API
2.5.1. Message format
2.5.2. RESOLVED status codes
2.5.3. Further name resolution behavior
2.6. Cancelling a name resolution request
2.7. Launching name plugins [INITENVVARS]
2.8. Name plugin workflow [NSBEHAVIOR]
2.8.1. Name plugin shutdown [NSSHUTDOWN]
2.9. Further details of stdin/stdout 
communication
2.9.1. Message Format
3. Discussion
3.1. Using second-level domains instead of tld
3.2. Name plugins handling all tlds '*'
3.3. Deployment strategy
3.4. Miscellaneous discussion topics
4. Acknowledgements
A.1: Example communication Tor <-> name plugin 
[PROTOEXAMPLE]
A.2: Example plugins [PLUGINEXAMPLES]

1. Introduction

   This proposal specifies a modular API for integrating name systems with Tor.

1.1. Motivation

   Tor onion service addresses are decentralized and self-authenticated but
   they are not human-memorable (e.g. 3g2upl4pq6kufc4m.onion). This is a source
   of poor usability, since Internet users are familiar with the convenient
   naming of DNS and are not used to addresses being random text.

   In particular, onion addresses are currently composed of 16 random base32
   characters, and they look like this:

  3g2upl4pq6kufc4m.onion
  vwakviie2ienjx7t.onion
  idnxcnkne4qt76tg.onion
  vwakviie2ienjx6t.onion

   When Proposal 224 get deployed, onion addresses will become even
   bigger: 53 base32 characters. That's:

llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymle.onion
lfels7g3rbceenuuqmpsz45z3lswakqf56n5i3bvqhc22d5rrsza.onion
odmmeotgcfx65l5hn6ejkaruvai222vs7o7tmtllszqk5xbysola.onion
qw3yvgovok3dsarhqephpu2pkiwzjdk2fgdfwwf3tb3vgzxr5kba.onion

   Over the years Tor users have come up with various ad-hoc ways of handling
   onion addresses. For example people memorize them, or use third-party
   centralized directories, or just google them everytime.

> Additionally, onion service providers have sometimes placed effort
> in creating more readable and memorable names, for example:
>
>   facebookcorewwwi.onion

   We believe that the UX problem of non-human-memorable problems is not
   actually solved with the above ad-hoc solutions and remains a critical
   usability barrier that prevents onion services from being used by a wider
   audience.

1.2. Design overview and rationale

   During the past years there has been lots of research on secure naming and
   various such systems have been proposed (e.g. GNS, Namecoin, etc.).

   Turns out securely naming things is a very hard research problem, and hence
> It turns out that ..
   none of the proposed systems is a clear winner: all of them carry various
   trade-offs. Furthermore, none of the proposed systems has seen

Re: [tor-dev] Onioncat and Prop224

2016-10-08 Thread grarpamp 
On Thu, Jun 23, 2016 at 3:51 PM, grarpamp  wrote:
> Freenet has talk on their lists of adding 100 new onioncat nodes
> to tor and i2p as linked to in this thread...
>
> https://lists.torproject.org/pipermail/tor-dev/2016-June/011108.html

More folks blogging related to the above...

http://mh7mkfvezts5j6yu.onion/2016/08/18/using-freenet-over-tor.html

This post outlines a method of using Freenet over Tor based on posts I
wrote on my Freenet hosted blog and subsequent discussions about it.
If you read my Freenet hosted blog there's little new here, I'm just
making it available on my non-freenet blog.
One issue I've had with Freenet is that it exposes your IP address to
peers. Recent law enforcement efforts to monitor Freenet have shown
that they have been able to obtain search warrants based on logging
requests for blocks of known data and associating them with IP
addresses. If law enforcement can do this, so can random bad people.
You can avoid exposing your IP address to random strangers on opennet
by using darknet but even then you have to trust your friends aren't
monitoring your requests. If it was possible to run Freenet over Tor
hidden services then only the hidden service address would be exposed
using this logging method. A problem is that Freenet uses UDP which
Tor does not support.
https://emu.freenetproject.org/pipermail/devl/2016-June/039056.html
A recent post on the Freenet development mailing list pointed out that
onioncat provides a virtual network over Tor and tunnels UDP. Using
the steps they provided, and some tweaks, it's possible to set up a
darknet node that doesn't expose its IP address. It uses the onioncat
generated IPv6 address for communicating with peers - and this address
is backed by a Tor hidden service.
The steps below outline how to set this up.
... details inside ...


https://lists.cpunks.org/pipermail/cypherpunks/2016-October/032674.html

I've been taking a somewhat different approach. I'm also using OnionCat,
but I focused first on anonymously reaching peers via the open Internet.
I have a node that hits the Internet through an "anonymous" VPS proxy.
The node reaches the proxy via IPv6 OpenVPN via OnionCat. The node binds
locally only to tun1, and in the proxy, tun1 forwards to eth0.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

2016-10-08 Thread Jesse V 
On 10/08/2016 08:50 AM, 61wxg...@vfemail.net wrote:
> How about specifying whether the Namecoin domain should point to .onion
> or clearnet in the domain?  We can require that TLDs for such service
> must end in either:
> 
> o o: The name points to a .onion name.
> 
> o i: The name points to an IP address.
> 
> o a: The name points to a clearnet domain name.
> 
> So example.zkeyo points to 66tluooeeyni5x6y.onion.  example.zkeyi
> points to 192.0.2.1 or (and?) 2001:db8::1.  example.zkeya points to
> example.com.

I don't think this is in scope of a naming system API. The naming system
probably has its own rules and users should be aware of those rules when
they use the naming system. For example, the Onion Name System (OnioNS)
will likely use ".tor" and I enforce that names must point to either
".tor" or ".onion", thus keeping it all internal. During my trial tests
today, the client code followed a chain until ".onion".

This is an API for onion services, so it doesn't make sense to handle
clearnet TLDs. There are other and easier ways of doing that, such as
alternative DNS roots.

-- 
Jesse



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] Proposal 274: A Name System API for Tor Onion Services

2016-10-08 Thread 61wxgp60 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Why run a separate process instead of using unix socket or TCP socket?


Since a Namecoin domain can point to IP addresses and ICANN-based DNS
names in addition to onion service names, and a Namecoin domain owner
might wish to switch between these configurations without causing
downtime or forcing their users to change behavior, I recommend against
this.  However, see the open question below:



Open question: If a Namecoin domain points to an onion service, end
users might expect encryption to be built in, and this assumption will
be violated if the Namecoin domain switches to using an IP address.
However, Namecoin domains can include TLS fingerprints, which would be
enforced for both the IP address and the onion service address.  Is it
sufficient to tell users that TLS is required if they want encryption
for Namecoin-addressed services, or is some additional mechanism
needed here to avoid bad things?


How about specifying whether the Namecoin domain should point to .onion
or clearnet in the domain?  We can require that TLDs for such service
must end in either:

o o: The name points to a .onion name.

o i: The name points to an IP address.

o a: The name points to a clearnet domain name.

So example.zkeyo points to 66tluooeeyni5x6y.onion.  example.zkeyi
points to 192.0.2.1 or (and?) 2001:db8::1.  example.zkeya points to
example.com.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJX+OqnAAoJEOoKZxebCIumIh0P/RaIZj9XYNngI6fVIcwQRGt9
OV9xPWNKkf53TcDi7HkkQLw5QerSe+Qmu6aMYBJ1J3s32QliX6Za+/AAfXwQ+051
JxOZKcg0RKGbTrjPMkF6mptkfSf+Xjkc8C5/BQp9TNcuy/CYmG88Soud7GidngW4
6lNvgJumxlP6YxpDvVg+VXpk8ry7k8kugoiKsFBKKFWYoEXUkDGRSXXLUiqC7hpv
N6UleRnK7eeHBFu3K76l9j8tuW33xohomKdLf33BB4E1XBUQnPfw6DRdRns0IlqX
BnWed7GGdd9ToQcWFKbRopYLRyTT7VX9IpgP1DJ689xchad8xnWcEz57aevyUlZ3
WaP5Vdrd3n/btYxAMbX65smAR98bkxSSr3NlFlpnympGnlgNW8bXtB6bjD2OQvmU
uBLTXZsJWyCZAWGmVk5XJUU6leieZz6DLCQTRk36qWfHT5/0E6bDsvdUUQAWfw9M
uHMoNKmVMXxTUhmQx3AVifQZ1w30jD/7ZsyF/Us3L0RpcUrCZKLvoDs5SIfD/VVe
SCGFXYPC9VMxF+ElrmyrRC/IEGxEOgegdRwdSnnVi73PuOU2cxIR2iYyj845AE8f
/JMN2rwULDVaxyREAhDafZRojkcJmQgv/prqN8U890Ihc2MUiGhgIqeDxCSAfwqN
w6sZ30pOL9/BiBKzmTto
=mMR3
-END PGP SIGNATURE-


-
75% of Americans don't like Clinton or Trump.
Don't waste your vote, say 'No' to the US Oligarchy and give it to Gary Johnson.
(paid for by VFEMail)

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  
___

tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

2016-10-08 Thread i9nvrppj 
Hi,

Why run a separate process instead of using unix socket or TCP socket?

> Since a Namecoin domain can point to IP addresses and ICANN-based DNS
> names in addition to onion service names, and a Namecoin domain owner
> might wish to switch between these configurations without causing
> downtime or forcing their users to change behavior, I recommend against
> this.  However, see the open question below:

> Open question: If a Namecoin domain points to an onion service, end
> users might expect encryption to be built in, and this assumption will
> be violated if the Namecoin domain switches to using an IP address.
> However, Namecoin domains can include TLS fingerprints, which would be
> enforced for both the IP address and the onion service address.  Is it
> sufficient to tell users that TLS is required if they want encryption
> for Namecoin-addressed services, or is some additional mechanism
> needed here to avoid bad things?

How about specifying whether the Namecoin domain should point to .onion
or clearnet in the domain?  We can require that TLDs for such service
must end in either:

o o: The name points to a .onion name.

o i: The name points to an IP address.

o a: The name points to a clearnet domain name.

So example.zkeyo points to 66tluooeeyni5x6y.onion.  example.zkeyi
points to 192.0.2.1 or (and?) 2001:db8::1.  example.zkeya points to
example.com.

Vina Gaff



signature.gpg
Description: application/pgp-encrypted
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev