Re: [DNSOP] An approach to DNS privacy

Phillip Hallam-Baker <hallam@gmail.com> Tue, 11 March 2014 15:39 UTC

Return-Path: <hallam@gmail.com>
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 071DD1A03F7 for <dnsop@ietfa.amsl.com>; Tue, 11 Mar 2014 08:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 b49umnHoSjMv for <dnsop@ietfa.amsl.com>; Tue, 11 Mar 2014 08:39:24 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id C7CBB1A0471 for <dnsop@ietf.org>; Tue, 11 Mar 2014 08:39:23 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id 10so5640396lbg.7 for <dnsop@ietf.org>; Tue, 11 Mar 2014 08:39:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OfL7+7qcUR99CeOKud0uEvuUsr6C0qFE34FnU3+eh8U=; b=Omso/y+gFVTxlFC0nz2djK2DWCELcBWzn1xEX1HlJSBf12IHXrdm+a/GtSy09scSB9 8V4iIOFvPjSc5Iu9whhkNdwVYxri/fMB8FLqGduwGSQsTe3OsxW0j/VlLzSiUwsJ4ArC smHLn4SkHrXBN+3CDczcwcYiTaze88C/B63r4ltWcNdF6y1bE6mnrhXZIJUmSug2BevM 0TcWZV7icMpZEugVrFez1eQObfcXt2KK7o/42toEtQsVG0K8s2ZUzFoOMI13sfNfVI0F TBHnqWHgCmVwc7HIiTJzlQFTOMskuymBlCW85JkwC3YUbjfJtJqQctk+cJahPzaTrEJC rwzA==
MIME-Version: 1.0
X-Received: by 10.112.200.130 with SMTP id js2mr1045293lbc.28.1394552357497; Tue, 11 Mar 2014 08:39:17 -0700 (PDT)
Received: by 10.112.37.168 with HTTP; Tue, 11 Mar 2014 08:39:17 -0700 (PDT)
In-Reply-To: <20140311152651.GB6740@nic.fr>
References: <CAMm+LwgZOPvGX_mzqmpt1zDj3cZdF0y2du=Di5q8Vfo4aYjNYw@mail.gmail.com> <87lhwj8y4d.fsf@mid.deneb.enyo.de> <20140311152651.GB6740@nic.fr>
Date: Tue, 11 Mar 2014 11:39:17 -0400
Message-ID: <CAMm+LwjVMGC2Jf8B_TCQK9UdRDe2r2f5OM_kFEEp7w3Ecb8v5Q@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: multipart/alternative; boundary=001a11c331b6e3aff404f4568575
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/Edh0auCV7-GrTZL8n99fIHOBCF8
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Florian Weimer <fw@deneb.enyo.de>
Subject: Re: [DNSOP] An approach to DNS privacy
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, 11 Mar 2014 15:39:29 -0000

On Tue, Mar 11, 2014 at 11:26 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr>wrote;wrote:

> On Sun, Mar 09, 2014 at 11:28:18AM +0100,
>  Florian Weimer <fw@deneb.enyo.de> wrote
>  a message of 20 lines which said:
>
> > In most jurisdictions, home networks use recursive resolvers whose
> > operators are required by law to provide cleartext copies to local
> > authorities.
>
> This (and other similar privacy-invasive cases) is precisely why we
> need to improve DNS privacy.
>
> > Encryption won't change that.
>
> As mentioned in draft-bortzmeyer-dnsop-privacy-sol, encryption is
> _one_ solution, it is not _the_ solution. At least two other
> techniques can complement encryption, QNAME minimization and a caching
> resolver on your own machine (possibly forwarding to the IAP's
> resolvers).
>
> > If it is about securing broadcast media, just run IPsec between the
> > CPE and the first ISP router with trusted ARP and routing tables.
>
> If it were so simple ("just run"), why isn't it pervasive?
>

The point is not to merely encrypt, the point is to allow control over the
encryption. That is:

* The client knows that the request/response SHALL be encrypted

* The client and server both know that they are the only parties that could
disclose the key


-- 
Website: http://hallambaker.com/