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

[Philip Homburg <[e-mail]>]

>> In a well designed system, names are only used to name things.
>
>I disagree, I think.
>
>In a "well designed" system, a name is meaningful to different parties
>differently. We can use it as a person's easy to remember name, or we
>can use it to express a relationship, or we can use it to ensure that
>related things are seen as related in a mathematical sense, or other
>things or all of these things and then more.

Yes, a name has no direct connection to what is named. And the system
doesn't encode any semantics in the name.

DNS gets pretty close to that. Which is quite amazing for such a large
scale distributed naming system.

And to be clear, the .onion domain violates that. The .onion suffix 
directly encodes that this name is to be used for onion routing. Also
the label in front of it has semantics to the system, instead just being
a user chosen name.

>I'm in favor of the DNS serving as a global petname system. When we
>use DNS to exchange keys as a kind of hack, we're using it badly as a
>petname system. We also do so without query privacy in most cases, so
>we find ourselves having bad petname system and with terrible privacy
>properties.

Solving the key exchange 'hack' in context of DNS is quite easy. In the
context of secure connections, the identifier for the remote party is a 
hash of the public key. In this setting, a network address is mostly
a locator.

So define an new 'IN PKhash_AAAA' type for DNS that combines the hash of
a public key with an IPv6 address and you can directly set up a secure
connection. No problem there because DNS can name arbitrary things.

You are completely right that DNS has no regard for privacy. However, the
way forward there is to come up with a naming system that has those
properties in addition to those of a naming system.

Maybe that can be done be extending DNS, maybe something else is required.

However, it is very clear that .onion is not such a naming system. It may
provide privacy, but it's not a naming system.

>> From the good old days, telnet and ftp are clear examples.
>> After looking up the name in DNS, you don't need the name anymore.
>> All you need are the addresses that were returned in the DNS lookup.
>
>Those are not protocols that do not provide confidentiality, integrity
>or authenticity. They do not solve hard problems. Once they start to
>solve harder problems, we start to see the problem with treating a
>name as *just* an easy to remember string, which it isn't.

Naming is almost never easy. But name has to be just an easy to remember
string. Otherwise, you have a broken naming. In particular, encoding meaning
in names almost always leads to a lot of pain.

>> With the interduction of the http host header, http also violates this
>> principle. With the introduciton of SNI, TLS violates it.
>>
>> However, SMTP, HTTP, and TLS have one in common, from the
>> network point of view, the name is not used for routing.
>
>The name in HTTP and SMTP are most certainly used for routing. It is
>just a very weak, non-cryptographic routing. With TLS, it is a
>stronger kind of cryptographic routing but still weak to an adversary
>performing surveillance.

Viewed from the Internet, HTTP and SMTP do hardly any routing based on 
the domain name. Of course, very large sites may still have complex routing
but that is hidden within that site (or in application layer tunnels, 
proxies, etc.).

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

In the context of a document identifier, a URL is an address and not a name.

A URL decribes how and where to find the document. It is not the name
of the document.

A 'self authenticating' anything implies that system level meaning is
encoded. And therefor it is not a name.

>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'm not at all suggesting that it would be less work. A quick hack is
in the short run almost always cheaper. It is in the long run that
the real costs start to show up.

>I think that since DNS is not a private system so your suggestion
>won't be done as easily as possible. If we had query privacy, I could
>imagine a world where such a suggestion could be workable. We don't
>live in that world though and so application developers can choose now
>to protect users from harm or they can pretend that it isn't their
>department. Or that another department could handle it better and so
>the buck is theirs to pass.

I completely agree that either DNS should get query privacy or that 
DNS should be replaced by something that has.

However, that mostly unrelated to the current discussion, which in my
opinion is mostly giving users access to tor hidden servers with minimal
changes to existing software. Instead adding direct support for tor
(even if that would just be: forward anything with 'onion://' or
'http://[onion:' or whatever we can come up with, to a proxy).

Anything that places onion 'names' where they belong, as the level of
addresses and not at the level of domain names.

>Pervasive monitoring is an attack (per RFC 7258) and RFC7686 is an
>attempt to mitigate, imperfectly, a failure exploited by surveillance.
>Personally, I would have preferred a much stronger RFC that forbids
>the transmission of any unencrypted DNS queries with additional
>restrictions that again, protect actual users.

I hope that once the dust of DNSSEC settles a bit, there will be time and
energy to solve the privacy problem.