Re: [DNSOP] Some thoughts on special-use names, from an application standpoint

[str4d <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jacob Appelbaum wrote:
> Hi,
> 
> On 11/29/15, Philip Homburg <[e-mail]> 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-----