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

Alec Muffett <alecm@fb.com> Thu, 10 December 2015 18:04 UTC

Return-Path: <prvs=97861959be=alecm@fb.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7F81A92AB for <dnsop@ietfa.amsl.com>; Thu, 10 Dec 2015 10:04:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.122
X-Spam-Level: **
X-Spam-Status: No, score=2.122 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTMrabqxngY7 for <dnsop@ietfa.amsl.com>; Thu, 10 Dec 2015 10:04:34 -0800 (PST)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA20E1A924B for <dnsop@ietf.org>; Thu, 10 Dec 2015 10:04:16 -0800 (PST)
Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBAI4BWc022593; Thu, 10 Dec 2015 10:04:16 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=dNuZ0Ocaf89WpMaI9GM5zPP5qvKWGGcKf1Ddf30bZpI=; b=YUIDb9f4TXJIorOvkwBmkPdjrov/mFeAh+1Km6g0e/njsfsfx/6CDOqGDz1nccNaGn3E /gWK9wD1CnF3JUTX3uxCPIqYJYOIVuGY7BOsH+5yBXqvC5u1pqqsWJ90bRC2jYeCOXg3 0ZcaDFntEQQk2SKRarQad4vx58QJ2jwVw+s=
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 1yqdu7060x-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Dec 2015 10:04:16 -0800
Received: from PRN-MBX02-4.TheFacebook.com ([169.254.2.160]) by PRN-CHUB14.TheFacebook.com ([fe80::5977:3d0b:700b:8bb%12]) with mapi id 14.03.0248.002; Thu, 10 Dec 2015 10:04:15 -0800
From: Alec Muffett <alecm@fb.com>
To: George Michaelson <ggm@algebras.org>
Thread-Topic: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
Thread-Index: AQHRJ0PG/a6gdbdgjUO1lJiswi447p68VjCAgAeI5ICAAEbwgIAAAcGAgAD6KAA=
Date: Thu, 10 Dec 2015 18:04:14 +0000
Message-ID: <9CB6F558-EC90-4879-83E3-7D57CC9E21FC@fb.com>
References: <20151205034455.41869.qmail@ary.lan> <F7A215E6-3699-4B01-9DB2-22ED014B9C9D@fb.com> <alpine.OSX.2.11.1512092200280.44949@ary.local> <CAKr6gn3njHDZTKEqfMP0p4T399p0_i5PTF55R=L3ebNLd2=eZQ@mail.gmail.com>
In-Reply-To: <CAKr6gn3njHDZTKEqfMP0p4T399p0_i5PTF55R=L3ebNLd2=eZQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.52.123]
Content-Type: multipart/signed; boundary="Apple-Mail=_6EDE98D7-E8AC-48A2-BA93-F4A28B7679F3"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-10_09:, , signatures=0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/jxRra0GzD-P26POd02djRW8JqlU>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, John R Levine <johnl@taugh.com>
Subject: Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2015 18:04:36 -0000

> On Dec 10, 2015, at 03:08, George Michaelson <ggm@algebras.org> 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 <johnl@taugh.com <mailto:johnl@taugh.com>> wrote:
> With onion you get a rather different thing that looks like an open
> 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, johnl@taugh.com <mailto:johnl@taugh.com>, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> 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=>
>