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

Jacob Appelbaum <> Sun, 29 November 2015 13:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DD831A0276 for <>; Sun, 29 Nov 2015 05:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YfnjFjj_iS2s for <>; Sun, 29 Nov 2015 05:50:42 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 923061A0235 for <>; Sun, 29 Nov 2015 05:50:41 -0800 (PST)
Received: by wmec201 with SMTP id c201so121739796wme.0 for <>; Sun, 29 Nov 2015 05:50:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D0KEXATRArKfFULaSI6jDiSD3kbY6AENOTKt1SjUTV0=; b=PB8+rTqHlp/U+HzfTpIyOETFKkhLTtXZEfwwsoUDozMkqeIUPs03Buvimmttpq/XdT MXKRKRU5w24U1enNjgW088m4EBlOrIqo3UOtuf+XvSr60RiWeREkUAdVvYGSGsXDYQ8o J4SlbC+So/ZI4zcoVKXM5Lx2d9O4VQLkOoWJwtULKUMftrjWpqAm9lX6673RAIBUfR5q OAQsUgaXn6yagzWJqOXO9cVLc/7+LP56rZ+S1S8BH3uXtybeTQ8TIbo5h23vJ8uaYl83 8j13hNX/4sA0TmWbsFT6vXNjvM4ma4n4aEpyjI2JNkrLpQpH/6VP9FeGEOc/Y4Tw4DJx GBAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=D0KEXATRArKfFULaSI6jDiSD3kbY6AENOTKt1SjUTV0=; b=Jzp79IxGNk8G4Z7NpYncKhl+VJ5/dKMdPG+xZjvKKJDqnpCjNXihnIoLFgiEo9QdFV TtvR2EZTk/b2jQVWJRKJEQ0JssCkUVD8ueYdzC4MkrKqXAvaWutJ0ZDIqg5UsohNcBWs McsW+7CPZ25NuuVf0/jVUbF0hJTzE+5g/67xZYALMVT1lOxbX0P1JNoFgDTcn+ysLzaD ve6HxAI+2E6kFKNxHUKmDq/ksGRMnmDT8MuCIBq2MMdnignKG/YNx8eY/Q4YWjcEdTIC 3RdXALAapN4ISENMvF1swbxxb2iNgEIuHJ4E0FbreCP5vDnwH9nJuivsQI+bQ03TydN8 1r2g==
X-Gm-Message-State: ALoCoQlviPY+eQIYFaAxPh2uwuMPLUiGGO+aD16pzc6bmKSyXeCxJmlkKlN6zJIUiJiIivJUI+8c
MIME-Version: 1.0
X-Received: by with SMTP id y138mr21804308wme.47.1448805040087; Sun, 29 Nov 2015 05:50:40 -0800 (PST)
Received: by with HTTP; Sun, 29 Nov 2015 05:50:39 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
Date: Sun, 29 Nov 2015 13:50:39 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Philip Homburg <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc:, Mark Nottingham <>, George Michaelson <>
Subject: Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
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: Sun, 29 Nov 2015 13:50:44 -0000


On 11/29/15, Philip Homburg <> 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

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


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

Specifically from the XKeyscore ruleset we published ( ):

requires grammar version 5
 * Aggregate Tor hidden service addresses seen in raw traffic.
mapreduce::plugin('anonymizer/tor/plugin/onion') =
: 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)
        else if(!onion.has_scheme())

      if (!onion.has_address())
        return false;, 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"] =
      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;

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,