Re: [perpass] DNS confidentiality

"Wiley, Glen" <gwiley@verisign.com> Mon, 11 November 2013 19:27 UTC

Return-Path: <gwiley@verisign.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A042D21E80E1 for <perpass@ietfa.amsl.com>; Mon, 11 Nov 2013 11:27:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.969
X-Spam-Level:
X-Spam-Status: No, score=-5.969 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffV9sKi2t-0e for <perpass@ietfa.amsl.com>; Mon, 11 Nov 2013 11:27:35 -0800 (PST)
Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00A11E8231 for <perpass@ietf.org>; Mon, 11 Nov 2013 11:27:29 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUoEvoJZq+jaXpElMjaEhlJ/KJG7aMwyJ@postini.com; Mon, 11 Nov 2013 11:27:35 PST
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rABJRPTx027732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 14:27:25 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 11 Nov 2013 14:27:25 -0500
From: "Wiley, Glen" <gwiley@verisign.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Thread-Topic: [perpass] DNS confidentiality
Thread-Index: AQHO3tdpEyY4uADSC0SfyXgM4tps8ZogamiA
Date: Mon, 11 Nov 2013 19:27:25 +0000
Message-ID: <CEA6999F.25B2C%gwiley@verisign.com>
In-Reply-To: <20131111121027.GA31723@sources.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <BA8DCD39EAD1754C8A1FE8EB6CC5CDDA@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: perpass <perpass@ietf.org>, Andy Wilson <andrewgwilson@gmail.com>
Subject: Re: [perpass] DNS confidentiality
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2013 19:27:42 -0000

Stephane,

Thanks for taking the time to capture this issue in a draft. I am very
supporting of providing a means to make DNS confidential.

A few comments from a reviewers perspective:

Section 3.2:

I realize that this is obvious, but it might be worth noting that there is
often (typically) a network connection made to the subject of a DNS query
sent from a stub resolver.  For example after sending a query for
www.example.com I am likely to make a connection via TCP to the address
returned.  This fact reduces the value of obscuring DNS queries at the
last mile unless the most aggressive measures are taken (a VPN or tunnel).
If an eavesdropper can dump traffic on the wire then they will see
outbound connections to www.example.com and so it doesn't really matter
whether they were able to see the DNS query.

Section 3.3.3:

While I agree with the sentiments in this section, is this in scope for
this draft?  This feels a little more like a reprise of arguments in favor
of DNSSEC which does not address privacy at all.

Section 4:

There is enough overlap between sections 4 and 3.3 that I would combine
section 4 and section 3.3 to address the problem of properly handling
packet traces and captured DNS traffic in a way that protects end user
privacy.

Section 6.1

It feels as though this section dives into the solution rather than the
problemŠ.something that needs to be done, but it feels out of scope for
this draft.  This could be addressed by changing the abstract of the draft
or by reducing the content in this section.



-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.




On 11/11/13 7:10 AM, "Stephane Bortzmeyer" <bortzmeyer@nic.fr> wrote:

>On Wed, Sep 25, 2013 at 02:40:59PM +0200,
> Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote
> a message of 13 lines which said:
>
>> May be starting with the more modest but certainly useful "DNS
>> privacy considerations" Internet-Draft? Such a document, just
>> documenting the problem, would be a good idea, IMHO.
>
>Done. 
>http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy
>_______________________________________________
>perpass mailing list
>perpass@ietf.org
>https://www.ietf.org/mailman/listinfo/perpass