Re: [DNSOP] DNS privacy : now at least two drafts

Florian Weimer <fw@deneb.enyo.de> Sat, 08 March 2014 16:51 UTC

Return-Path: <fw@deneb.enyo.de>
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 4C9991A02C7 for <dnsop@ietfa.amsl.com>; Sat, 8 Mar 2014 08:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 iToMj7Pg_aPr for <dnsop@ietfa.amsl.com>; Sat, 8 Mar 2014 08:51:02 -0800 (PST)
Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id D2AF11A02CE for <dnsop@ietf.org>; Sat, 8 Mar 2014 08:51:01 -0800 (PST)
Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WMKSd-0001X1-Nm; Sat, 08 Mar 2014 17:50:55 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from <fw@deneb.enyo.de>) id 1WMKSd-0003X7-J3; Sat, 08 Mar 2014 17:50:55 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
References: <20131217112527.GA18176@nic.fr>
Date: Sat, 08 Mar 2014 17:50:55 +0100
In-Reply-To: <20131217112527.GA18176@nic.fr> (Stephane Bortzmeyer's message of "Tue, 17 Dec 2013 12:25:27 +0100")
Message-ID: <87ob1geis0.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/JIE4jcR7He1fiCYVdwMXS_FGHpY
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] DNS privacy : now at least two drafts
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: Sat, 08 Mar 2014 16:51:04 -0000

* Stephane Bortzmeyer:

> I just posted a new version of the DNS privacy draft,
> draft-bortzmeyer-dnsop-dns-privacy-01. The most important difference
> is that it is now split in two, one pure problem statement,
> draft-bortzmeyer-dnsop-dns-privacy and an exploration of possible
> solutions, draft-bortzmeyer-dnsop-privacy-sol. The first one seems to
> me (and to the AD) well adapted to dnsop. The second one mixes
> solutions that may be in the realm of dnsop (such as qname
> minimization) and solutions that would require a new WG (such as
> encryption of DNS traffic).

The -sol draft mentions QNAME minimization without defining the term.
Is this about sending only as many labels as required to obtain a
delegation from an authoritative server?

There is another privacy-enhancing approach that is not mentioned in
the draft: defensive delegations.  For example, with current resolver
behavior, the lack of a delegation for 1.E164.ARPA means that queries
under that tree are sent to the E164.ARPA servers, which are scattered
around the globe.  With a delegation, the delegation would be cached
and queries could be kept locally in the region.