Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
Jacob Appelbaum <jacob@appelbaum.net> Sun, 29 November 2015 13:50 UTC
Return-Path: <jacob@appelbaum.net>
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 2DD831A0276 for <dnsop@ietfa.amsl.com>; Sun, 29 Nov 2015 05:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfnjFjj_iS2s for <dnsop@ietfa.amsl.com>; Sun, 29 Nov 2015 05:50:42 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923061A0235 for <dnsop@ietf.org>; Sun, 29 Nov 2015 05:50:41 -0800 (PST)
Received: by wmec201 with SMTP id c201so121739796wme.0 for <dnsop@ietf.org>; Sun, 29 Nov 2015 05:50:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.28.175.144 with SMTP id y138mr21804308wme.47.1448805040087; Sun, 29 Nov 2015 05:50:40 -0800 (PST)
Received: by 10.28.173.80 with HTTP; Sun, 29 Nov 2015 05:50:39 -0800 (PST)
X-Originating-IP: [37.187.114.36]
In-Reply-To: <m1a31k6-0000HVC@stereo.hq.phicoh.net>
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>
Date: Sun, 29 Nov 2015 13:50:39 +0000
Message-ID: <CAFggDF1R_ArP-fH9RY8CsbZ5kBkZiCvnuNJmuf3mtYmLZGfFHA@mail.gmail.com>
From: Jacob Appelbaum <jacob@appelbaum.net>
To: Philip Homburg <pch-dnsop@u-1.phicoh.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/J-BesKbHXsqGwigBK615-fM2W_w>
Cc: dnsop@ietf.org, Mark Nottingham <mnot@mnot.net>, George Michaelson <ggm@algebras.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 13:50:44 -0000
Hi, On 11/29/15, Philip Homburg <pch-dnsop@u-1.phicoh.com> 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
- [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