Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
Paul Wouters <paul@nohats.ca> Tue, 17 March 2015 01:14 UTC
Return-Path: <paul@nohats.ca>
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 D0EDE1ACDA9 for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 18:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Level:
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_75=0.6, T_RP_MATCHES_RCVD=-0.01] 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 4yW11thpt59a for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 18:14:44 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C391A8AAB for <dnsop@ietf.org>; Mon, 16 Mar 2015 18:14:43 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l5c3g2prcz1HF; Tue, 17 Mar 2015 02:14:39 +0100 (CET)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Qq3wsxlV
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wrrxY5n90LBX; Tue, 17 Mar 2015 02:14:38 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 17 Mar 2015 02:14:38 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 78967819A0; Mon, 16 Mar 2015 21:14:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426554876; bh=k2vzv2JoBSvijBgtAKWY6i3oxBoSYtlvRLowL+P6v5s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Qq3wsxlVCbovwHcWu4ErXa7KEURAM9lHJGlWiNwFd4Ia0mqvBfksgjMUCNeeUR71W 3sMvDOGH8BFjFH6nlKziz011LecK3k66carUnr1iy7ku9YmTXCrx7hEYFQclZcvaYf e56k0EpZ28LgpMLkkYy+ihwPD2Jjd9JCUQm2CyoY=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2H1EZda025704; Mon, 16 Mar 2015 21:14:35 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 16 Mar 2015 21:14:35 -0400
From: Paul Wouters <paul@nohats.ca>
To: Jacob Appelbaum <jacob@appelbaum.net>
In-Reply-To: <CAFggDF0XX3v7yGsaCwFnE7cjK0yz4-frxFgoBJfnztO8k-LFBg@mail.gmail.com>
Message-ID: <alpine.LFD.2.10.1503162052420.20709@bofh.nohats.ca>
References: <CAFggDF0XX3v7yGsaCwFnE7cjK0yz4-frxFgoBJfnztO8k-LFBg@mail.gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/FU9P4MyZGmY6XMqZdG4K1DhM-nY>
Cc: Alec Muffett <alecm@fb.com>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
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: <http://www.ietf.org/mail-archive/web/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: Tue, 17 Mar 2015 01:14:49 -0000
On Mon, 16 Mar 2015, Jacob Appelbaum wrote: > Subject: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt Is this meant to replace or augment draft-grothoff-iesg-special-use-p2p-names ? > - most importantly is the date October 1st. On that date we'll have a > death day for currently issued certifcates with .onion names. This > makes the onion name issue rather time sensitive and without further > action, some stuff will likely break. How does the certificate "dead line" affect (non-)DNS for .onion? I have reviewed the document and I'm not sure what is intended? I think it is meant as advise to DNS implementors? I guess it is an attempt to reduce .onion leaks if those happen to hit the DNS infrastructure? If so, I would think a much shorter document could be written that only talks about stub resolvers and caching resolvers, stating they should never forward any of these queries but return something - and I'm not sure if NXDOMAIN is the best answer if these resolvers cannot go out to fetch the real DNSSEC proof needed to authoritatively say so. SERVFAIL might be better. Although, if draft-ietf-dnsop-qname-minimisation becomes an RFC, and I'm pretty sure that it will, then actually processing the query would not leak that much information anymore, as only the "onion." request will go out (and get cached) and proper DNSSEC proof will come back denying its existance, without leaking the fake FQDN onion address. >> Htmlized: http://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-00 The Tor network [Dingledine2004] has the ability to host network services using the ".onion" Top-Level Domain. Well, it does not because there is no Top-Level Domain of ".onion" and we have the cryptographic proof of that in the root zone. Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion, and SHOULD NOT perform a DNS lookup. If an application does not implement tor, and is not tor aware, it _will_ do a DNS lookup. You can't really go ask the world to stop doing that. You need to deal with that fact. Resolvers that implement the Tor protocol MUST either respond to requests for .onion names by resolving them (see [tor-rendezvous]) or by responding with NXDOMAIN. Other resolvers SHOULD respond with NXDOMAIN. Again, stating what software that is not TOR aware should do is a lost cause. They will just think it is a real DNS query and process it that way. Resolvers that do support Tor and that for some "tor reason" are returning NXDOMAIN are going to hit DNSSEC validation failures if the application using that resolver is DNSSEC aware. The NXDOMAIN has to come with some NSEC/NSEC3 proof. In a way, you are lucky because there is such a the proof - because it _really_ does not exist. But it means any resolver can return that proof for "legitimate" tor domains as well, which I would guess is some kind of a security issue for tor aware applications using a system or network bassed resolver? 4. Caching DNS Servers: Caching servers SHOULD NOT attempt to look up records for .onion names. They SHOULD generate NXDOMAIN for all such queries. 5. Authoritative DNS Servers: Authoritative servers SHOULD respond to queries for .onion with NXDOMAIN. Well, they already do? Because it does not exist! Users must take special precautions to ensure that the .onion name they are communicating with is correct, as attackers may be able to find keys which produce service names that are visually or apparently semantically similar to the desired service. Also, users need be aware of the difference between a .onion name used and accessed directly via Tor-capable software, versus .onion subdomains of other TLDs and providers (e.g., the difference between example.onion and example.onion.tld). I don't think an RFC can tell enduers what to do or expect? If client software attempts to resolve a .onion name, it can leak the identity of the service that the user is attempting to access to DNS resolvers, authoritative DNS servers, and observers on the intervening network. This can be mitigated by following the recommendations in Section 2 It could also be mitigated by actually configuring a .onion zone, but your document states that's really unwanted. Why? Paul
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… David Conrad
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… David Cake
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Rubens Kuhl
- [DNSOP] discussion for draft-appelbaum-dnsop-onio… Jacob Appelbaum
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Paul Wouters
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… hellekin
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Paul Wouters
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… hellekin
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Alec Muffett
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Christian Grothoff
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… David Conrad
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… hellekin
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Alec Muffett
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… David Conrad
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Richard Barnes
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Tim Wicinski
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… David Conrad
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Alec Muffett
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Rubens Kuhl
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… David Cake
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Alec Muffett
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Hugo Maxwell Connery
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… hellekin
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… David Conrad
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Ted Lemon
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Alec Muffett
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Rubens Kuhl
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Alec Muffett
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Rubens Kuhl
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Tom Ritter
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Richard Barnes
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Andrew Sullivan
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Andrew Sullivan
- [DNSOP] draft-grothoff (was Re: discussion for dr… David Conrad
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… hellekin
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Ted Lemon
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Florian Weimer
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Edward Lewis
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Andrew Sullivan
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… joel jaeggli
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Warren Kumari
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… John Levine
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Alec Muffett
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Andrew Sullivan
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Hugo Connery
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… hellekin
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Alec Muffett
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… hellekin
- Re: [DNSOP] discussion for draft-appelbaum-dnsop-… Alec Muffett