Subject: Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

From: "John Levine" <[email-masked]>
Date: 5 Dec 2015 03:44:55 -0000

It occurs to me that there's a difference between local and localhost
on the one hand and onion on the other.  With local and localhost, you
still something like an A or AAAA record with an an IP address that
you can use in the normal way to open a connection.

With onion you get a rather different thing that looks like an open
TCP connection, a couple of levels up the protocol stack.  So if the
theory is that these special names are doing a protocol switch, it's
not one switch, it's potentially a switch per name.  I suppose you
could say there's yet another switch for test, example, and invalid
that returns failure at whatever level of the stack you try.

I'm not sure if that makes the discussion notably more complicated
but it certainly doesn't make it any simpler.

R's,
John

---

From: Alec Muffett <[email-masked]>
Date: Wed, 9 Dec 2015 22:48:48 +0000

Hiya!

> On Dec 5, 2015, at 03:44, John Levine <[email-masked]> wrote:
> 

Strictly an Onion address yields you a _real_ TCP connection to your SOCKS server, which tunnels that to the remote endpoint, connecting to a _real_ (though potentially synthesised) TCP Port Number at the server.

I find it simplest to think of Onion addresses as akin to using a SOCKS proxy to connect to an alternative Layer-3-address space, out on a VPN somewhere.

I find it hard to get particularly exercised about "Where does Tor sit in the 7-Layer Model" when I haven't successfully yet answered that for SOCKS.  :-)

The Onion addresses aren't making a "protocol switch", they're merely constrained to TCP in the same way SOCKS is; and in much the same way that it is possible to ask a SOCKS proxy to connect you to 192.168.23.45 on port 22, it is equally possible to ask Tor to connect you to someonionaddress.onion on port 22. Or 25, 80, 443, or whatever, so long as a listener has been configured on the other end.

    -a

---

From: "John R Levine" <[email-masked]>
Date: 9 Dec 2015 22:02:35 -0500

>> TCP connection, a couple of levels up the protocol stack.

> Strictly an Onion address yields you a _real_ TCP connection to your 
> SOCKS server, ...

It's certainly a virtual circuit, but it's not a TCP connection because 
the endpoints aren't IP addresses.

> The Onion addresses aren't making a "protocol switch", ...

Really, they are.  You can't do a DNS lookup on the address, there is no A 
or AAAA record with an IP address to which you can open a TCP connection.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: George Michaelson <[email-masked]>
Date: Thu, 10 Dec 2015 13:08:51 +1000

The 7 Layer model is a useful tool to talk about things, its not a rei-fied
thing. That said, apparent layer violations invite critique because they
inherently carry architectural consequence.

I think the overloading of a (semantic space) name to have special
properties to take it out of the system is a case in point. Its an
application through session layer property: packets don't get sent using
.onion labels in source/destination fields. And the imposition on all the
other layers to handle .onion specially, feels (to me) a mortal wound.
This, compared to the cost of taking syntactic limits in the URI, and
applying a lever there to wedge :tor: into the URI form, denoting what you
want to happen.

SOCKS is pretty much a shim. Its a clean layer impact. Its (to me) like
taking fopen() and replacing it by bzip2fopen() to get silent bz2
capability in existing file I/O

On Thu, Dec 10, 2015 at 1:02 PM, John R Levine <[email-masked]> wrote:

> Strictly an Onion address yields you a _real_ TCP connection to your SOCKS
>> server, ...
>>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Alec Muffett <[email-masked]>
Date: Thu, 10 Dec 2015 18:04:14 +0000

> On Dec 10, 2015, at 03:08, George Michaelson <[email-masked]> wrote:
> The 7 Layer model is a useful tool to talk about things, its not a rei-fied thing. That said, apparent layer violations invite critique because they inherently carry architectural consequence.

Very true. :-)

> I think the overloading of a (semantic space) name to have special properties to take it out of the system is a case in point. Its an application through session layer property: packets don't get sent using .onion labels in source/destination fields.

Also true; most Tor Onion clients currently perceive Tor access as a (TCP) circuit to a SOCKS Proxy server which forwards packets onwards into a magic virtual network space where the layer-3-equivalent addresses are written strangely, indeed echoing the format of DNS addresses somewhat.

:-)

This is, of course, a complete heresy.  All "real" network engineers know that "real" network addresses are written as dotted-quads of decimal numbers, like "127.0.0.1", except for newer ones where "real" network addresses are written like "::1" a-la RFC5952

The browser manufacturers - brazen fools that they are - have gone FAR beyond these bounds, delved deep into namespaces where the only the foolish will tread, and will allow URIs to represent otherwise pure, unsullied network addresses in non-canonical but supposedly equivalent ways such as:

0177.0.0.1
0x7f.0.0.1
127.0.1
127.1
2130706433
017700000001
0x7f000001

- and (worse!) because of Tim Berners-Lee's lack of foresight in using a colon to separate host from port, the ideal, visual purity of an RFC5952 IPv6 address must therein be encumbered with brackets - [square brackets!] - when used in a URL!

HAS THIS INSANITY NOT GONE ON FOR TOO LONG ALREADY?

And now, this upstart "Onion" thing.  An 80-bit binary address which is encoded in base32?

WHY BASE32? SURELY THERE IS NO PRECEDENT FOR USING BASE32?

THE HUMAN EYEBALL ALREADY CANNOT COPE WITH THE VARIETY OF ENCODINGS WHICH ARE IN USE ON THE MODERN INTERNET!

And worse: They FLAGRANTLY SUFFIX this 80-bit binary blob (16 characters base32) with a string: ".onion" - to FLAUNT its difference!

What arrant perversion, the like of which we have not seen the like since X.25 NUAs & NSAPs!

We should all march on the Tor office and Tell them!  We should tell them to convert to Dotted Quads like any RESPECTABLE protocol does, so they can use:

  http://122.152.229.227.20.102.54.239.123.210/

...which is FAR more obvious than "facebookcorewwwi.onion".

Specifically: it is far more obvious that users would not be able to survive with such addresses without using DNS.

Which is good, because that's what DNSOP loves to talk about.

    - alec (`dd if=cheek of=tongue`) :-P

ps: Back when I was a young system administrator we had to remember addresses like 2342192001006995 and 00001300000001.FTP.MAIL; kids today have got it easy.

> And the imposition on all the other layers to handle .onion specially, feels (to me) a mortal wound. This, compared to the cost of taking syntactic limits in the URI, and applying a lever there to wedge :tor: into the URI form, denoting what you want to happen.
> 
> SOCKS is pretty much a shim. Its a clean layer impact. Its (to me) like taking fopen() and replacing it by bzip2fopen() to get silent bz2 capability in existing file I/O
> 
> On Thu, Dec 10, 2015 at 1:02 PM, John R Levine <[email-masked] <mailto:[email-masked]>> wrote:
> Strictly an Onion address yields you a _real_ TCP connection to your SOCKS server, ...
> 
> It's certainly a virtual circuit, but it's not a TCP connection because the endpoints aren't IP addresses.
> 
> Really, they are.  You can't do a DNS lookup on the address, there is no A or AAAA record with an IP address to which you can open a TCP connection.
> 
> Regards,
> John Levine, [email-masked] <mailto:[email-masked]>, Taughannock Networks, Trumansburg NY
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=T4UdyZF0g0I68UQdhjA_7A&m=ik7lMLqVVD8RLJ7MsB5cpctpfTj0ReD7tSvh88_miBc&s=ugYLtgSFAm8Krhwe0cKsgzpnrETYvUGL3evvpzmMMxg&e=>
>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Dec 2015 20:41:05 +0000

>but it certainly doesn't make it any simpler.

I think this slices the problem space in two incorrect ways.

First, given an identifier, it's not always an address you want.

Second, the purpose of an identifier is access information about an
object.  If the information is an address, how that address is reached is
beyond the scope of the identifier within the context of resolving then
name.

What I'm leading to is, it doesn't matter to a naming system that Tor will
route packets one way or another, that's up to the forwarding code to
determine.  I might get a 32 bit numeric value understood to be a IPv4
address for a mDNS name or for a Tor name when I am done resolving the
name.  The code that used the mDNS name will then open a channel to that
address for the purposes of doing what it wants to do, the code that
accessed the Tor name will, well, do the same.

This isn't all about addresses though.  Identifiers can be used to refer
to an object in physical space to grab stored data about it, stored in a
database.

There's talk about protocol switches.  I think that's a misnomer.  There
are resolution switches.  I see a lot of utility in it being the top-level
name in a Domain Name.  (I'm not ready to say that's the best way to go.)
The alternative is to have the resolution method identified in meta- or
ancillary- information, like the schema of a URL (http://).  Doesn't the
HTTP:// definition though allow the "authority name" to be anything that
looks like a host or domain name but doesn't have to be a DNS name?
That's what makes me prefer the in-name implicit way of identifying the
resolution method.

(Sorry for handwaving while trying to work on a detailed document to
prevent the need from handwaving.  But it seems more convenient to respond
this way.)

Every name/identifer space has to live in a context.  There are way more
identifiers than objects because of differing perspectives or contexts.
Contexts can overlap, e.g., one context could be all protocols (and
applications built on them) related to the IETF.  A list of IETF protocols
would be rather impossible to make, too long, too many gray areas, etc.,
but then again, the list doesn't have to be a firm boundary for what uses
a set of identifiers.  So long as the "client/initiator" and the
"server/recevier" of the identifier agree on the context, they'll get by.

---

From: "John R Levine" <[email-masked]>
Date: 11 Dec 2015 12:43:19 -0500

> name in a Domain Name.  (I'm not ready to say that's the best way to go.)

Until .onion, the protocol switch for all of the special names was at the 
point where you map a name into an IP address, since localhost and .local 
give you a real IP that you use the same way as any other IP.  You can 
open a TCP socket for web or submit, you can send UDP packets for DNS, you 
can send ICMP packets for ping.  For .test, .example. and .invalid. the 
mapping always fails.

Now .onion comes along and the switch is at a different layer, at whatever 
level SOCKS is.  You can open TCP-like virtual circuits, you might be able 
to do DNS if your SOCKS driver simulates UDP, you can't do ping ping, 
since SOCKS doesn't simulate ICMP.

.onion is a special case for a variety of reasons, but it's not clear to 
me whether people think that slicing at the SOCKS level rather than the 
address resolution level is an exception, or we will be defining a new 
application API for every new special name.

R's,
John