Re: [DNSOP] my dnse vision

Francis Dupont <Francis.Dupont@fdupont.fr> Wed, 05 March 2014 14:46 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
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 311D11A0039 for <dnsop@ietfa.amsl.com>; Wed, 5 Mar 2014 06:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 keX0j7f-78wI for <dnsop@ietfa.amsl.com>; Wed, 5 Mar 2014 06:46:37 -0800 (PST)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 408AC1A06C6 for <dnsop@ietf.org>; Wed, 5 Mar 2014 06:46:22 -0800 (PST)
Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s25EkITX083212; Wed, 5 Mar 2014 15:46:18 +0100 (CET) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201403051446.s25EkITX083212@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: Dan York <york@isoc.org>
In-reply-to: Your message of Wed, 05 Mar 2014 12:11:16 GMT. <CF3CB64B.68DB9%york@isoc.org>
Date: Wed, 05 Mar 2014 15:46:18 +0100
Sender: Francis.Dupont@fdupont.fr
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/6kbNZZoh6tG1GWma-9LHYlipLrM
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] my dnse vision
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: Wed, 05 Mar 2014 14:46:39 -0000

 In your previous mail you wrote:

>  > I consider the first one to be already solved, cf. the Microsoft
>  > deployed solution which puts clients, local networks, the resolver
>  > (also the Microsoft Domain Server :-), in the same area and uses
>  > IPsec to protect it.
>  
>  Which may be great if you are: 1) in an environment using Microsoft
>  solutions; and 2) connected to those networks.

=> I gave this as a deployed example for the stub <-> resolver
where the resolver is local and under your control (the second is
likely if it is a DNSSEC validating resolver too).

>  Not so great if you are NOT in a Microsoft environment

=> I am very far to be a Microsoft addict (:-)! But if Microsoft can
do it (or enforce it to its customers) there is no reason you can't do
it too...

>  or are mobile or on other networks (and
>  yes, I realize you could VPN back into the corporate network).

=> you took words from my mouth: just go back to the known case
(note in this case you are likely leaking the corporate name but
nothing else).

>  >You can do other ways but IMHO we can assume
>  >you don't need confidentiality with far or untrusted resolvers.
>  >Or with other words you don't need confidentiality with 8.8.8.8
>  
>  And I will disagree with that assumption.

=> I make the assumption the resolver is under your control
(so by definition it is not an open recursive resolver :-).
This is more about what means confidentiality in this context,
so a topic by itself.

>  I personally want confidentiality between my stub resolver and
>  whatever recursive resolvers I may choose to use, including 8.8.8.8
>  (and its IPv6 equivalent). I'd like to remove that connection as a
>  place where an attacker can monitor / observe / log my DNS queries.

=> to go further we need to know what/if open recursive resolver
operators (there are only a few) want to do, and if they want
the IETF to charter a WG to design something. IMHO it is very
different from the initial perpass concern so should be addressed
(if it needs to be addressed) independently.

Regards

Francis.Dupont@fdupont.fr

PS: for ISP recursive resolvers the issue is simpler: DNS is a part
of the ISP service and to protect it is just an easy sub case to
protect ISP customers' communications. With other words either
you trust your ISP, you don't trust it and there are a lot of
things more critical than the DNS.