[tor-dev] Expanding services: Single-onion and OnioNS

[Hugo Maxwell Connery <hmco@xxxxxxxxxx>]

Hi,

Having reviewed the last couple of months of tor-dev mails,
i can see that there are many proposals afoot to expand the
uptake of tor hosted services.  These range from a new service
type, single-onion [0], to load balancing of tor hosted services
[1], to hosting new name/value pairs (x-namespace) [2], to new
name services (OnioNS [3] and better integration of Gnu NS [4]),
to name a few that caught my eye.

The fact that Facebook (which I wholely dislike) expended
considerable effort in generating a human readable location hidden
service address and then strongly participated in IETF discussions
to declare .onion as a special case TLD reservation indicates
that the perception of the validity and significance of the tor
network is growing.

I have comment on single-onion services and on name services.

For single onion services, in which client -> guard -> middle
-> middle -> single-onion, the role of the second middle relay
changes.  In the traditional sense it merely knows that it is
part of a circuit connecting two relays, and has no knowledge
at all about either source (client) or destination (normal web
service).  For single onion services the second middle relay
can know something about the service to which it is connecting.

As Yawning Angel points out [5] this may provide censorship
opportunities.  For this, I suspect that single onion service
operators need to be made aware of this risk.  If they are aware,
they can persue strategies to mitigate (e.g run multiple contact
points over a back end).

John Brooks identifies [6] a potential risk for the second
middle relay operator if the single onion service is malicious
(keeps detailed logs, runs a honeypot etc.).  For this case,
and to help peole who provide large capacity middle relays (e.g
Mozilla) and wish for no legal risk, a config flag may need to
be provided which allows middle relays to choose not to connect
to single onion services.  There may be other, better strategies.

I wish also to highlight the potential importance of Jesse V's
OnioNS [7].  I am highly supportive of alternatives to the DNS,
which despite efforts ongoing in the IETF, will never be secure
against surveillance.  OnioNS attempts to solve Zooko's triangle.
It seems a well considered name system, and I encourage
others to examine it.

The key benefits are that a service can choose a name for itself,
but must do work to do so, and must regularly do work to maintain
the name (thus costing squatters effort).  The name service
operates entirely within the location hidden services space and
thus offers the protections inherent in that.  Registration is
at the second level (e.g example.tor) but can also at the same
time register lower levels names (e.g xmpp.example.tor and
gopher.example.tor).

Regards,  Hugo

[0] https://lists.torproject.org/pipermail/tor-dev/2015-September/009408.html

[1] https://lists.torproject.org/pipermail/tor-dev/2015-September/009597.html

[2] https://lists.torproject.org/pipermail/tor-dev/2015-September/009588.html

[3] https://lists.torproject.org/pipermail/tor-dev/2015-September/009585.html

[4] https://lists.torproject.org/pipermail/tor-dev/2015-September/009560.html

[5] https://lists.torproject.org/pipermail/tor-dev/2015-September/009416.html

[6] https://lists.torproject.org/pipermail/tor-dev/2015-September/009415.html

[7] https://github.com/Jesse-V/OnioNS-literature/raw/master/conference/conference.pdf
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev