Re: [perpass] DNS confidentiality

"Wiley, Glen" <gwiley@verisign.com> Thu, 14 November 2013 19:50 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 CFFBC11E80FA for <perpass@ietfa.amsl.com>; Thu, 14 Nov 2013 11:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.28
X-Spam-Level:
X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, 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 STU4lzh6IL87 for <perpass@ietfa.amsl.com>; Thu, 14 Nov 2013 11:49:44 -0800 (PST)
Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7A31421F9C6A for <perpass@ietf.org>; Thu, 14 Nov 2013 11:49:42 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUoUpViUipfzx2jQ9MYa8UxXv4uf9rH2s@postini.com; Thu, 14 Nov 2013 11:49:44 PST
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rAEJnf5O015694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 14:49:41 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 14 Nov 2013 14:49:40 -0500
From: "Wiley, Glen" <gwiley@verisign.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Thread-Topic: [perpass] DNS confidentiality
Thread-Index: AQHO3tdpEyY4uADSC0SfyXgM4tps8ZogamiAgAGvn4CAAJf+gIAA+6eA//+tbwCAAKmQgIABIvMA
Date: Thu, 14 Nov 2013 19:49:39 +0000
Message-ID: <CEAA9288.264A5%gwiley@verisign.com>
In-Reply-To: <20131113212817.GB8596@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="us-ascii"
Content-ID: <6285048E1035494DBD05660926A700C8@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: perpass <perpass@ietf.org>
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 IETF discussion of pervasive monitoring. " <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: Thu, 14 Nov 2013 19:50:06 -0000

On 11/13/13 4:28 PM, "Stephane Bortzmeyer" <bortzmeyer@nic.fr> wrote:

>On Wed, Nov 13, 2013 at 04:21:26PM +0000,
> Wiley, Glen <gwiley@verisign.com> wrote
> a message of 150 lines which said:
>
>> While I certainly support the idea of confidential DNS, I wonder
>> whether it is a good idea to impose the overhead involved in TLS on
>> the high volume name servers?
>
>First, it may not be TLS. I mention dnscrypt and there is also at
>least one (not published yet) proposal to encrypt DNS without TLS (or
>DTLS).

Thanks - I had TLS on the brain while I was reading.

>
>Second, I do not think we want to impose anything ("MUST encrypt all
>queries and MUST accept encrypted queries"...) My vision is that some
>servers will adopt encryption and not all. The resolvers will have to
>decide (local policy) what to do if the remote server does not support
>encryption.

The idea of making it opportunistic makes sense to me.

>
>This approach seems the only realistic one, for incremental
>deployment. An interesting consequence is that the end-user will have
>trouble knowing if his queries are encrypted or not (specially if his
>resolver uses a forwarded).

I agree.  If he uses a secure transport then one way for the end user to
know whether the queries are encrypted is to handle the iteration himself
and hit the authoritative servers directly rather than query a recursive
resolver.  In order to do anything more definite we would need to alter
the DNS protocol.

>