Re: [DNSOP] reservations on reservations, was Barry Leiba's Abstain

Mark Andrews <marka@isc.org> Tue, 01 September 2015 22:28 UTC

Return-Path: <marka@isc.org>
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 866711B4BAB for <dnsop@ietfa.amsl.com>; Tue, 1 Sep 2015 15:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 NvTPaKrLK3hz for <dnsop@ietfa.amsl.com>; Tue, 1 Sep 2015 15:28:21 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1584B1B478B for <dnsop@ietf.org>; Tue, 1 Sep 2015 15:28:20 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 95FB21FCC3C; Tue, 1 Sep 2015 22:28:16 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7FD6E16003D; Tue, 1 Sep 2015 22:29:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 55CD81600AE; Tue, 1 Sep 2015 22:29:36 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id d70UpPN5BC5G; Tue, 1 Sep 2015 22:29:36 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id E0A7416003D; Tue, 1 Sep 2015 22:29:35 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7AA1D36A0F75; Wed, 2 Sep 2015 08:28:10 +1000 (EST)
To: Joe Abley <jabley@hopcount.ca>
From: Mark Andrews <marka@isc.org>
References: <20150901143500.63585.qmail@ary.lan> <7A6FBF85-A86B-46F1-B4EC-C015AEE598C9@difference.com.au> <alpine.OSX.2.11.1509011137110.13159@ary.lan> <CAFggDF2wrCK6ANLKTGuuK4M4VcyO9X+YEd4fgv15pf_jkP+JvA@mail.gmail.com> <CA40D404-C43B-4BF4-8F66-E6DD755286EE@hopcount.ca>
In-reply-to: Your message of "Tue, 01 Sep 2015 13:27:19 -0400." <CA40D404-C43B-4BF4-8F66-E6DD755286EE@hopcount.ca>
Date: Wed, 02 Sep 2015 08:28:10 +1000
Message-Id: <20150901222810.7AA1D36A0F75@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/E8Pp0eev-v7-3Pz_ukmBVIQFUMA>
Cc: John R Levine <johnl@taugh.com>, dnsop@ietf.org, David Cake <dave@difference.com.au>, Jacob Appelbaum <jacob@appelbaum.net>
Subject: Re: [DNSOP] reservations on reservations, was Barry Leiba's Abstain
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: Tue, 01 Sep 2015 22:28:22 -0000

In message <CA40D404-C43B-4BF4-8F66-E6DD755286EE@hopcount.ca>, "Joe Abley" writ
es:
> 
> 
> On 1 Sep 2015, at 11:45, Jacob Appelbaum wrote:
> 
> > In my view and the DNS has a critical flaw: it does not provide query 
> > privacy.
> 
> You're on the wrong list. The people working on DNS privacy are over at 
> DPRIVE. For the problem statement, see RFC 7626, recently published.

DPRIVE are looking at stub to recursive resolver privacy.

This is recursive resolver to root server privacy which is off charter
for DPRIVE.

Now there are two ways to solve this as the root is signed.

1. Recommend *every* recursive server holds a copy of the root zone.
   This has implications for ICANN and how many TLD's they can sell
   as the root zone would need to remain relatively small.  This
   also helps with other leakage to the root zone.

2. Insecurely delegate .onion and recommend that every resolver
   synthesis a NXDOMAIN response.  This also has implication for
   ICANN as they don't have procedures to do this sort of delegation.

3. Hope that QNAME minimisation gets deployed to all stub resolvers.

2 and 3 both leak that a onion name is being looked up but not what that
name is.

> Joe
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org