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

[Jacob Appelbaum <[e-mail]>]

Hi,

On 11/29/15, Philip Homburg <[e-mail]> wrote:
>>> The purpose of the domain name system is to name things. We have IP
>>> addresses and we want to refer to them using names. We do the same thing
>>> with mail domains, etc.
>>
>>That is not the sole purpose - we use DNS for keys, for time stamps,
>>for data of all kinds.
>
> 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.

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.

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

> SSH with SSHFP also has that property. Lookup the SSH fingerprint in
> the SSHFP record, lookup an address, connect, and verify the fingerprint.
> No need for the name after the lookup.
>
> (Storing other stuff in a naming system is not a problem, it is just a
> big distributed database).
>

I think the idea that it is considered primarily a naming system is a
bit strange once you make the above concession. It is effectively a
government and corporate distributed database with almost no privacy
or security protections against those operating or monitoring the DNS.

> From day one however, this principle was violated. SMTP does use the
> domain name after the name lookup.
>
> 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.

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

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

Part of my motivation for this work comes from the following revelation:

  http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html

Specifically from the XKeyscore ruleset we published (
http://daserste.ndr.de/panorama/xkeyscorerules100.txt ):

// START_DEFINITION
requires grammar version 5
/**
 * Aggregate Tor hidden service addresses seen in raw traffic.
 */
mapreduce::plugin('anonymizer/tor/plugin/onion') =
  immediate_keyword(/(?:([a-z]+):\/\/){0,1}([a-z2-7]{16})\.onion(?::(\d+)){0,1}/c
: c++
    includes: {{
      #include <boost/lexical_cast.hpp>
    }}
    proto: {{
      message onion_t {
        required string address = 1;
        optional string scheme = 2;
        optional string port = 3;
      }
    }}
    mapper<onion_t>: {{
      static const std::string prefix = "anonymizer/tor/hiddenservice/address/";

      onion_t onion;
      size_t matches = cur_args()->matches.size();
      for (size_t pos=0; pos < matches; ++pos) {
        const std::string &value = match(pos);
        if (value.size() == 16)
          onion.set_address(value);
        else if(!onion.has_scheme())
          onion.set_scheme(value);
        else
          onion.set_port(value);
      }

      if (!onion.has_address())
        return false;

      MAPPER.map(onion.address(), onion);
      xks::fire_fingerprint(prefix + onion.address());
      return true;
    }}
    reducer<onion_t>: {{
      for (values_t::const_iterator iter = VALUES.begin();
          iter != VALUES.end();
          ++iter) {
        DB["tor_onion_survey"]["onion_address"] = iter->address() + ".onion";
        if (iter->has_scheme())
          DB["tor_onion_survey"]["onion_scheme"] = iter->scheme();
        if (iter->has_port())
          DB["tor_onion_survey"]["onion_port"] = iter->port();
        DB["tor_onion_survey"]["onion_count"] =
boost::lexical_cast<std::string>(TOTAL_VALUE_COUNT);
        DB.apply();
        DB.clear();
      }
      return true;
    }});

/**
 * Placeholder fingerprint for Tor hidden service addresses.
 * Real fingerpritns will be fired by the plugins
 *   'anonymizer/tor/plugin/onion/*'
 */
fingerprint('anonymizer/tor/hiddenservice/address') = nil;
// END_DEFINITION

Please note the first comment in that source code:

  "Aggregate Tor hidden service addresses seen in raw traffic."

How do we blind XKeyscore (and similar systems such as the Russian
SORM!) in a way that ensures users don't find themselves in such a
database? In browsers, with pre-fetching, I think the answer is
outlined in RFC7686. In other applications, I think the answer, if
someone cares about the user is also outlined in RFC7686.

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.

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.

All the best,
Jacob