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

[Jeremy Rand]

David Fifield:
> So here, the browser thinks it is connecting to debian.zkey (the URL bar
> says "debian.zkey"). But Tor is really connecting to sejnfjrq6szgca7v.onion
> in the background. What name does the browser put in its Host header? It
> can't be the onion name, because there's no feedback from the naming
> module back to the user application layer. It must be "debian.zkey"
> then. If that is a petname, then it just got leaked to the server. I can
> imagine this might also cause a problem with some virtual hosting setups
> (though I suppose those are not very common for onion services). If the
> user uses HTTPS, e.g. https://facebook.zkey/, then they'll get a TLS
> name mismatch error, even if https://facebookcorewwwi.onion/ exists and
> has a valid certificate--so using the naming system is not a transparent
> replacement for memorizing the onion address. Maybe non-HTTP protocols
> will also have problems.

In Namecoin's case, that's working as intended: if Facebook sets up a
Namecoin domain name, then they should create a TLS certificate with
their .bit domain on the SAN list, that TLS certificate should be listed
in their Namecoin name as a TLSA record, and it should be served when
the SNI header asks for the .bit domain.  It's unclear to me whether
that is problematic for other naming systems.  It's also unclear to me
whether this will be problematic if Facebook wants to get an EV
CA-issued cert to cover their .bit domain name, due to the political
issues around the P2P names proposal at IETF.

I'm aware that Alec Muffett isn't at Facebook anymore, but perhaps he
would be able to offer feedback on what issues might be likely to come
up here?

Cheers,
-Jeremy



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

[Jeremy Rand]

Hi George,

Here are my comments:

2.3.1

> If there are multiple name plugins that correspond to the requested
> address, Tor queries all relevant plugins sorted by their priority
> value, until one of them returns a successful result.

It's unclear whether the sort operation referred to here is ascending or
descending.

> If all plugins fail to successfuly perform the name resolution, Tor
> SHOULD default to using the exit node for name resolution.
> XXX or not?  because of leaks?

I would strongly recommend not using exit relays to resolve Namecoin
domains.  I recommend that if a locally specified Namecoin instance
fails to resolve a Namecoin domain, then the user should receive an
error, either stating that the domain doesn't exist, or that Namecoin
encountered a problem (depending on which is the case).

2.5.1

> where QUERY_ID is a unique integer corresponding to this query, and
> NAME_STRING is the name to be queried.

Some Namecoin resolution modes (in particular headers-only SPV clients)
will generate network traffic on lookups.  I therefore recommend that
sufficient information be passed in the RESOLVE line to allow the
Namecoin lookup network traffic for different requests to be
stream-isolated in the same way that the connections to the resulting
addresses would be stream-isolated.  (This is the same concern as
Arthur's feedback.)

> where QUERY_ID is the corresponding query ID and STATUS_CODE is an
> integer status code. RESULT is the resolution result (an onion
> address) or an error message if the resolution was not succesful.

Namecoin domain names can point to IP addresses and CNAMEs to
ICANN-based DNS names in addition to onion service addresses.  It is my
opinion that Namecoin domains that point to IP addresses and ICANN-based
DNS names are useful for Tor users, since they are resistant to some
censorship attacks (e.g. domain takedowns) and MITM attacks (because the
TLS fingerprint is obtained from the blockchain rather than trusting a
CA).  As such, I recommend that this message format be modified to allow
a name plugin to return an IP address or ICANN-based DNS name as an
alternative to an onion service address.

Open question: is it useful to allow multiple onion services addresses
or multiple IP addresses to be returned, for purposes of load balancing
or failover?  Letting Tor handle the selection of which address to pick
from the list might make stream isolation related issues easier to
handle safely.

2.5.3

> XXX NAME_RESOLUTION_TIMEOUT = ???

As one data point, the near-worst-case Namecoin lookup time I measured
in testing for the slowest lookup mode in my SPV client was between 2
and 3 seconds (over clearnet).  I don't know how much slower it would be
when routed over Tor.  Most queries are much faster than this worst-case
time, and I intend to attempt to optimize this.

> XXX should we also accept IPs and regular domain results???

Yes, I recommend this for the reasons listed in my 2.5.1 feedback.

> XXX perhaps we should make sure that results are not names that need
> additional name resolution to avoid endless loops. e.g. imagine
> some sort of loop like this:
>  debian.zkey -> debian-bla.zkey -> debian.zkey -> etc.

Open question: is it beneficial (for example) for a Namecoin name to
point to an OnioNS name?

2.6

> Tor might need to cancel an ongoing name resolution request
> (e.g. because a timeout passed, or the client is not interested in
> that address anymore). In this case, Tor sends the following line to
> the plugin stdout as follows:

I'm curious what the intended use case is for this.  In the case of
Namecoin, I'm guessing it's probably harmless to just let the request
time out on Namecoin's end.  Is there a reason this matters for other
naming systems (which I'm less familiar with) more than Namecoin?

3.1

> People have suggested that users should try to connect to
> reddit.zkey.onion instead of reddit.zkey. That is, we should always
> preserve .onion as the tld, and only utilize second-level domains for
> naming.

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?

3.4

> Does it make sense to support reverse queries, from .onion to names?
> So that people auto-learn the na

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

[meejah]

George Kadianakis  writes:

I have skimmed over this proposal, and it all sounds plausible. This:

>In the beginning, name plugins should be third-party applications that can
>be installed by interested users manually or through package managers. 
> Users
>will also have to add the appropriate OnionNamePlugin line to their torrc.
>This will be a testing phase, and also a community-growing phase.

...made me think: couldn't the whole proposal be implemented via a
controller (with MAPADDRESS)?

That is, the controller registers to re-map streams, and for every
request to e.g. "^*.corn$" it speaks the proposed lookup protocol to the
registered plugins. That is, the whole approach could be more-quickly
prototyped in e.g. Python, and if it works well could them be
implemented in C in Tor proper (but the actual name-looking-up plugins
would all still work).

In any case, I like it :)

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

[David Fifield]

On Fri, Oct 07, 2016 at 04:06:51PM -0400, George Kadianakis wrote:
>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

Is there any meaning intended by the near-collision in the 2nd and 4th
addresses?

>If all plugins fail to successfuly perform the name resolution, Tor SHOULD
>default to using the exit node for name resolution.
>XXX or not?  because of leaks?

It would be really nice if it were possible for the browser to show some
kind of UI indication that a name I type into the URL bar is going to be
handled specially. Even now, the URL bar is magical: if you typo a DNS
name, the browser does a web search and leaks whatever you just typed. I
think in the protocol as proposed, there's no way for the browser to
predict whether a name will be looked up in a special way using a
plugin, or even to learn what the mapping was after it has occurred.

How do you think this will interact with attacker-controlled names in
HTML? Let's say someone has a local petname database where
"bank.petname" points to the onion site of their bank. What happens when
HTML says
http://bank.petname/favicon.ico";>
Will it show the icon of the user's bank, whatever bank it happens to
be? I guess my question is if attackers are allowed to query the user's
local naming setup, even in an indirect way, or does the magic only
happen for names that are typed directly into the URL bar? (Because the
mapping happens below the SOCKS layer, I guess it could not apply only
to the URL bar.)

>Hence, the contribution of this proposal is a modular Name System API
>(NSA)

This acronym might cause confusion :)

>|
> $~~$
>|  1.$  4. GNS magic!! 
>  $
>|  User: SOCKS CONNECT to$ debian.zkey -> 
> sejnfjrq6szgca7v.onion$
>|http://debian.zkey/ 
> $~~$~~~$
>|   $
>  +-|-+ $
>  |+v-+ 2. +-+|   3.$
>  ||Tor   | debian.zkey|Tor  ||   debian.zkey 
> +-$---+
>  ||Networking->Naming   ->
>  |
>  ||Submodule ||Submodule||  Tor Name System API  |  
> GNS|
>  ||  <- <-  
> wrapper|
>  ||  | 6. | ||5. |
>  |
>  |+|-+ sejnfjrq6szgca7v.onion +-+|sejnfjrq6szgca7v.onion 
> +-+
>  +-|-+
>|  7.
>|  Tor: Connect to
>|   http://sejnfjrq6szgca7v.onion/
>v

So here, the browser thinks it is connecting to debian.zkey (the URL bar
says "debian.zkey"). But Tor is really connecting to sejnfjrq6szgca7v.onion
in the background. What name does the browser put in its Host header? It
can't be the onion name, because there's no feedback from the naming
module back to the user application layer. It must be "debian.zkey"
then. If that is a petname, then it just got leaked to the server. I can
imagine this might also cause a problem with some virtual hosting setups
(though I suppose those are not very common for onion services). If the
user uses HTTPS, e.g. https://facebook.zkey/, then they'll get a TLS
name mismatch error, even if https://facebookcorewwwi.onion/ exists and
has a valid certificate--so using the naming system is not a transparent
replacement for memorizing the onion address. Maybe non-HTTP protocols
will also have problems.

It would be nice if there were some standard external way to just do a
name→onion query. As specified, there's no easy way for e.g. the browser
to query how a name will be mapped, short of launching its own instance
of the GNS wrapper and communicating with the over the Name System API.
I wonder, perhaps there's a way to extend the Tor RESOLVE cell to
support this feature? So you could do, for example
$ tor-resolve debian.zkey
sejnfjrq6szgca7v.onion

>When launching name plugins, Tor sets various environment variables to pass
>data to the name plugin (e.g. NS API version, state directory, etc.). More
>information on the environment variables at [INITENVVARS].
> 
>After a name plugin initializes and parses all needed environment
>variables, it communicates with Tor using its stdin/stdout.

I worry that repeating the envvar and stdin/stdout design of the PT spec
will cause problems for p

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

[Arthur D. Edelstein]

Hi George,

A nice proposal!

A question that occurs to me is how the name plugin will interact with
the network. Presumably it will make requests over Tor, either
periodically to update its local database, or just-in-time, whenever a
RESOLVE request is made. If name resolution requires a just-in-time
connection, what circuit should this connection use? Right now, Tor
Browser uses a separate circuit for each URL bar domain ("first
party") to avoid linking visits to different websites. And thus DNS
resolution happens on each first-party's circuit. So I think something
similar needs to happen with name plugins, to avoid exposing all
resolution requests to a single exit node. Does this need to be part
of the API somehow?

Arthur

On Fri, Oct 7, 2016 at 1:06 PM, George Kadianakis  wrote:
> Hello list,
>
> we've been busy discussing secure name systems for the past few months,
> and how we could integrate them with Tor.
>
> We had a few people ask us for precise interfaces, so here is an attempt
> for a modular name system API. It's largely based on the PT API, which
> has been pretty successful.
>
> The proposal was brainstormed on a Sunday morning in Seattle between
> Yawning, David and me. I wrote the actual proposal contents so any
> innacuracies, impossibilities and errors are mine :)
>
> If people like it and are interested in implementing it, we can draft
> out an implementation plan for any person who wants to go for it. But
> for now, please consider this proposal text as a draft that is meant to
> be improved from this list's feedback.
>
> Have fun and looking forward to your comments (and code).
>
> ---
>
>
> 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
>   

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

[George Kadianakis]

Hello list,

we've been busy discussing secure name systems for the past few months,
and how we could integrate them with Tor.

We had a few people ask us for precise interfaces, so here is an attempt
for a modular name system API. It's largely based on the PT API, which
has been pretty successful.

The proposal was brainstormed on a Sunday morning in Seattle between
Yawning, David and me. I wrote the actual proposal contents so any
innacuracies, impossibilities and errors are mine :)

If people like it and are interested in implementing it, we can draft
out an implementation plan for any person who wants to go for it. But
for now, please consider this proposal text as a draft that is meant to
be improved from this list's feedback. 

Have fun and looking forward to your comments (and code).

---


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.

   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
   none of the proposed systems is a clear winner: all of them carry various
   trade-offs. Furthermore, none of the proposed systems has seen widespread use
   so far, which makes it even harder to pick a single project.

   Given the plenitude of options, one approach to decide which system
   is best is to make various decent name systems available and let the
   Tor community and the sands of time pic

[tor-dev] 0.2.9 freeze dates, and fun bugs to work on, and important code to review

[Nick Mathewson]

Hello, all!

Here is an incomplete list of takeaways from network-team meeting last
week, plus some more scheduling things, and other fun stuff for new
(and experienced) Tor developers!

  * 0.2.9 is now frozen for big/risky changes.  I'll put out the final
alpha around 14 or 17 Oct, and fork 0.3.0 then too.

  * I'll continue to accept small, safe changes in 0.2.9 through the
final alpha. Maybe a couple of days after. After that, I only plan to
take fixes for critical bugs, regressions, and security issues.

  * Here are the open tickets in the 0.2.9 milestone [1].  Note that
some of them have no owner! Many of them would be pretty easy for
somebody to fix, if you want something to work on over the next few
days. On the other hand, almost none of them seem
must-fix-before-0.2.9-or-the-sky-falls to me.  So if nobody works on a
patch for them over the next week or so, they're probably going to
have to wait for 0.3.0.

  * Here is the latest "review group" [2] -- a list of tickets where
I'm not planning to review new big stuff outside of this group until
everything in this group.  During the 0.2.9 development period, using
this method has gotten us to the point where we are reaching the final
weeks of development without a huge backlog of unreviewed code.
Writing reviews for this code can be a fun introduction to how Tor
works!


[1]  Open 0.2.9 tickets:
https://trac.torproject.org/projects/tor/query?status=!closed&milestone=Tor%3A+0.2.9.x-final&group=status&order=priority

[2] review-group-10:
https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~review-group-10&group=status&order=priority

all best wishes,
-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 273: Exit relay pinning for web services

[Nick Mathewson]

On Wed, Oct 5, 2016 at 4:09 PM, Philipp Winter  wrote:
> The proposal is in draft state.  We have several open questions that we
> are still wrestling with in Section 2.6.  Any feedback is greatly
> appreciated.  You can track the evolution of our proposal online:
> 

Added to the torspec repository.  Please keep sending patches / merge
requests to keep everybody synchronized.

(Also, everybody, please be aware that picking your own proposal
number sometimes causes collisions. This time, we all got lucky. No
worries.)

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

[tor-dev] CollecTor Release 1.0.2

[iwakeh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hi there!

CollecTor continues with a smaller release:

 https://dist.torproject.org/collector/1.0.2/

This release makes features available that have been
running on the main CollecTor [4] instance for a while now.

The three most significant changes for release 1.0.2:

* CollecTor provides Bifroest's descriptor data [1].
* A shutdown hook gives the running threads time to complete properly
  instead of simply terminating them [2].
* TCP ports are now replaced with hashes in @type bridge-network-status 1.1
  and @type bridge-server-descriptor 1.2 descriptors [3].

and some more listed in CHANGELOG.md of the tar-ball.

Cheers,
iwakeh

[0] https://dist.torproject.org/collector/1.0.2/
[1] https://trac.torproject.org/projects/tor/ticket/20037
[2] https://trac.torproject.org/projects/tor/ticket/19016
[3] https://trac.torproject.org/projects/tor/ticket/19317
[4] https://collector.torproject.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlf3ukkACgkQsANAxTOj/abFvwD/ap0UWbyMVUm/gL7zZarslLuM
ocTxr7Xr3VUjznxLPHsA/0it/ia7Ym1RvgB/bxKuefxcGB9n20dC4tVCAlJFwDAJ
=QgO8
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev