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

Alec Muffett <> Wed, 09 December 2015 22:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2A92F1B2F4A for <>; Wed, 9 Dec 2015 14:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DwY5TeUoEywa for <>; Wed, 9 Dec 2015 14:48:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B3E91B2F45 for <>; Wed, 9 Dec 2015 14:48:50 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id tB9MipB4021172; Wed, 9 Dec 2015 14:48:50 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=YdlfEcAbglOXdm2DJbj2VzsMogWbLmBsAjs89lD3pTg=; b=FQxlUWeg1255DY6RgoQUB5NP9ZfTelLa/6MLUL8ZpqUi3xS4dCo0ft2QkP3Z5IDPDmkF sDnftCS7/4Nv1oNR5AiwyPTv56QL1Za4sV2KxDuxehar0wi7QN+Yh2JRBJAiwl3xIcQl H3nRY0l7sZgZNWAO8PIUZWo42swiRcfsEy8=
Received: from ([]) by with ESMTP id 1yp5q1dr55-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Dec 2015 14:48:50 -0800
Received: from ([]) by ([fe80::8c35:7ba8:bb32:ee09%12]) with mapi id 14.03.0248.002; Wed, 9 Dec 2015 14:48:49 -0800
From: Alec Muffett <>
To: John Levine <>
Thread-Topic: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
Thread-Index: AQHRJ0PG/a6gdbdgjUO1lJiswi447p68VjCAgAeI5IA=
Date: Wed, 09 Dec 2015 22:48:48 +0000
Message-ID: <>
References: <20151205034455.41869.qmail@ary.lan>
In-Reply-To: <20151205034455.41869.qmail@ary.lan>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_43F45D9F-D075-4A70-AA78-2FF957EC44B8"; 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-09_09:, , signatures=0
Archived-At: <>
Cc: "" <>
Subject: Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Dec 2015 22:48:52 -0000


> On Dec 5, 2015, at 03:44, John Levine <> wrote:
> 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.

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 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.