Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
str4d <str4d@i2pmail.org> Sun, 29 November 2015 20:37 UTC
Return-Path: <str4d@i2pmail.org>
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 567CC1B33F3 for <dnsop@ietfa.amsl.com>; Sun, 29 Nov 2015 12:37:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.447
X-Spam-Level: *
X-Spam-Status: No, score=1.447 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_BRBL_LASTEXT=1.449, 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 KQsJWXp4COYC for <dnsop@ietfa.amsl.com>; Sun, 29 Nov 2015 12:37:33 -0800 (PST)
Received: from mail01.sigterm.no (mail01.sigterm.no [193.150.121.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A151B33F1 for <dnsop@ietf.org>; Sun, 29 Nov 2015 12:37:32 -0800 (PST)
Received: by mail01.sigterm.no (Postfix, from userid 1006) id B1BEF2E32E7; Sun, 29 Nov 2015 21:37:29 +0100 (CET)
Received: from smtp.postman.i2p (i2p-outproxy01.privacysolutions.no [193.150.121.66]) by mail01.sigterm.no (Postfix) with ESMTP id 796DF2E32AE for <dnsop@ietf.org>; Sun, 29 Nov 2015 21:37:25 +0100 (CET)
X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p
To: Jacob Appelbaum <jacob@appelbaum.net>, Philip Homburg <pch-dnsop@u-1.phicoh.com>
References: <80FD8D43-1552-4E10-97CD-9781FED204F2@mnot.net> <m1a30za-0000IuC@stereo.hq.phicoh.net> <CAFggDF1rPK63L8ua9crBB1nvnQ67JOYCQNHekzeO=jBXeDMK5Q@mail.gmail.com> <m1a31k6-0000HVC@stereo.hq.phicoh.net> <20151129135135.D7739AE500@smtp.postman.i2p>
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: str4d <str4d@i2pmail.org>
MIME-Version: 1.0
In-Reply-To: <20151129135135.D7739AE500@smtp.postman.i2p>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Message-Id: <20151129195732.6D14EAE4FB@smtp.postman.i2p>
Date: Sun, 29 Nov 2015 19:57:32 +0000
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/dCOzpoIa2HuT3XsrZye2d26bp6I>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
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: Sun, 29 Nov 2015 20:37:35 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Jacob Appelbaum wrote: > Hi, > > On 11/29/15, Philip Homburg <pch-dnsop@u-1.phicoh.com> wrote: >> >> It is only later, at the application layer that the name is used >> again. >> >> It is here that .onion goes one step further. Onion 'names' are >> derived from public keys. So instead a name being independent of >> an address, the .onion name is the address. > > The name is not an address per se. It is a self-authenticating url > - this means you can prove that you're talking to who you intended > to speak with all along. It says nothing of the routing, except > that you are routed by public key and IP addresses are not as > relevant. They're still used in some cases but the system is > designed to fail closed. > > This is not exactly the same as the .onion name being an address. > The *publickey* is also not an address. In the Tor Hidden Service > protocol, we have descriptors and other things that are more akin > to the address. They change often and are authenticated by the > public key that you would expect to authenticate them. Those > authenticated bits are the address in my view. > >> Unlike, TLS or SSH, where a network connection is set up and >> then the crypto runs on top of it, in TOR this all integrated. >> For good reason, however that make the .onion 'name' an address. > > It can be done in stages - transparent setups work differently > from a local Tor client, for example. A resover can be Tor enabled, > as a network, as a browser, etc. > > I guess I have a hard time calling the name an address. It is a > name and it is a kind of name with security properties. See also > Zooko's triangle for what I mean - the normal DNS and > self-authenticating names are not the same mapping on Zooko's > triangle. I concur with Jacob. An I2P Destination (the public keys defining a particular client or service) is essentially equivalent to an IP address, and .i2p domain names do essentially "resolve" to Destinations. Furthermore, a .b32.i2p is functionally equivalent to an .onion - it is a self-authenticating name, that has a one-to-one correspondence with an address-like network object (the Destination). But just because the .b32.i2p or .onion is derived from the address, IMHO does not mean it is not a name. For one thing, a .b32.i2p cannot be used in isolation to connect to an I2P HS - it must be looked up in-net to obtain the Destination. > >>>> In goes a name, out comes some lower level entity. >>>> >>>> In this context an onion address should have been an 'IN >>>> ONION', i.e, www.example.com might have an 'IN ONION' >>>> address for use with TOR. >>>> >>> >>> And that would also require special handling... >> >> Yes, but in a way that doesn't abuse the model. >> > > Perhaps. > >> If an 'IN ONION' would be stored on the host as a 'struct >> sockaddr_onion' then all code can be cleanly adapted to support >> TOR hidden services. Instead of adding pattern matching hacks to >> name resolution. >> > > I'm skeptical but I do look forward to you expanding on how this > would work with *less* work than our current approach. I'd also be > curious what work would need to be done and how it could be done > in a way that fails closed and does not harm the user's privacy. I actually looked into doing this for I2P several months ago ago (long after .i2p and .onion were proposed in the P2PNames draft, but before .onion was separately proposed and accepted), because the I2P network model would map well onto the existing getaddrbyhost() mechanisms. I concluded that defining AF_I2P (necessary to enable all code to be "cleanly adapted") would require patching the Linux kernel, the Windows kernel, and probably the kernels of any other OS you wanted to run it on, because none of them provide any way to define additional AF_* or PF_* either in userspace or via kernel modules. You *can* define the 'struct sockaddr_i2p' in a module, but it would have to co-opt some pre-existing and maybe-or-maybe-not-unused AF_*, which is a laughable approach. Now wind back ten years, to when I2P's decision to use .i2p was made. The network was far smaller then (a few hundred nodes, c/f ~40k today). Am I really expected to believe that the small group of pseudonymous developers at the time could have got AF_I2P supported across every OS they wanted I2P to run on (which was every OS that supported Java), in a reasonable space of time (e.g. shorter than this ML has been debating the P2PNames drafts)? When actually using it would require a per-OS kernel module that talked to a user-space usually-not-installed Java process? And when the alternative was to simply use an HTTP proxy that listens for .i2p addresses, which required very little work, was compatible with anything that supported HTTP proxies, and was functional for users immediately? I believe that without the backing of a major business or organization it would not happen now, and it certainly would never have happened back then. If I am wrong, and it *is* possible to define a 'struct sockaddr_i2p' with *less* work, I eagerly look forward to you explaining how :) str4d -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWW1ibAAoJEBO17ljAn7PgnNMQAI1oOdD0GNmzKHlN1xnAhXGy mPcQxhhh/cGGhmyvZjqliSYWQVWbNjCv8SXm2AXNKquCzScGcEsBjufzCY6lUb/k +MVabEGBtxxxQ4PZBBA2YsKjMR8HucMR/Q3wbF7QL9BcHXX6ZYpee9SPJh8kQ95b b7BLp7b/LmKpmebhlZoLWYXRev8NO5k2yOLuU5MzLpAAhnsQQSwd+TqtlEW7VmVD 8Tu/6MZ7IQgcvXrqYXQSnTa38GKGLjdZHj3a25qeiChxJWn8fvWdx0fLi9SaJWs0 P3dlOfmiE0zqkvt1tGFgxsdI4GeKNC2Mmjcmi3ljKUu/j9rR3nK1b7uz7kGdxowj 1svipDspOPAawlNEkVw8aO9Qf9ko1BR4UPsOERA5Emj/0ypP2gzZgCqRVv9NSaOK LZOFKjxkWx+hr17LFpJczUp2IkV8a38fFlXTEtYscX5eviPp494cVT/H0otVvNgT KErg4deCkyrmwycuMq/ZSop0K2EyyUaC4mp0Svfr0X84jWEk/XlH9Zfo4QZR0IsK 1yl1lqNINjJ2YFRIrN3rIRYIu4rCZ6HKcaclwO0lNV6hjsImpFwGwIUNtO6Dd+rM mCoQCNh35NWWldyZo/49MqCPRXOcpBMHByweXspOqjrJ+JMwAPBO54Az2JR2BbUG 96ViHcgL5GM/cnWYiOTZ =QOba -----END PGP SIGNATURE-----
- [DNSOP] Some thoughts on special-use names, from … Mark Nottingham
- Re: [DNSOP] Some thoughts on special-use names, f… hellekin
- Re: [DNSOP] Some thoughts on special-use names, f… George Michaelson
- Re: [DNSOP] Some thoughts on special-use names, f… Tim Wicinski
- Re: [DNSOP] Some thoughts on special-use names, f… Mark Nottingham
- Re: [DNSOP] Some thoughts on special-use names, f… Philip Homburg
- Re: [DNSOP] Some thoughts on special-use names, f… Jacob Appelbaum
- Re: [DNSOP] Some thoughts on special-use names, f… Philip Homburg
- Re: [DNSOP] Some thoughts on special-use names, f… Jacob Appelbaum
- Re: [DNSOP] Some thoughts on special-use names, f… David Conrad
- Re: [DNSOP] Some thoughts on special-use names, f… str4d
- Re: [DNSOP] Some thoughts on special-use names, f… Edward Lewis
- Re: [DNSOP] Some thoughts on special-use names, f… John Levine
- Re: [DNSOP] Some thoughts on special-use names, f… Philip Homburg