Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

Stephane Bortzmeyer <bortzmeyer@nic.fr> Thu, 09 January 2020 15:29 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFADC12004C; Thu, 9 Jan 2020 07:29:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jmyGkLY1gR9u; Thu, 9 Jan 2020 07:29:23 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BD0120019; Thu, 9 Jan 2020 07:29:23 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1E7D12804FC; Thu, 9 Jan 2020 16:29:22 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id 1724F2806AB; Thu, 9 Jan 2020 16:29:22 +0100 (CET)
Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 0F2862804FC; Thu, 9 Jan 2020 16:29:22 +0100 (CET)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 0BC5F642C581; Thu, 9 Jan 2020 16:29:22 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id 00DBB3FDEE; Thu, 9 Jan 2020 16:29:21 +0100 (CET)
Date: Thu, 09 Jan 2020 16:29:21 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Sara Dickinson <sara@sinodun.com>
Cc: Eric Rescorla <ekr@rtfm.com>, last-call@ietf.org, DNS Privacy Working Group <dns-privacy@ietf.org>, Martin Thomson <mt@lowentropy.net>
Message-ID: <20200109152921.GB28511@nic.fr>
References: <4639bd67-6fca-47d1-aaeb-85fcd0394f46@www.fastmail.com> <7E5F804D-535F-4CB3-8F7F-ABD0ED4B833A@sinodun.com> <CABcZeBON0ung2htbaiKWGKJSUsHrPhrcEfJgVDoO3+UYCQZxsg@mail.gmail.com> <7729E44B-38EB-4EAF-8EFF-ED286696373E@sinodun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7729E44B-38EB-4EAF-8EFF-ED286696373E@sinodun.com>
X-Operating-System: Debian GNU/Linux 10.2
X-Kernel: Linux 4.19.0-6-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Bogosity: No, tests=bogofilter, spamicity=0.000976, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ZV_svLImhdPl_s2DxFQPnVM1rZk>
Subject: Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2020 15:29:25 -0000

On Tue, Jan 07, 2020 at 06:37:38PM +0000,
 Sara Dickinson <sara@sinodun.com> wrote 
 a message of 278 lines which said:

> There is currently no standardized discovery mechanism for DoH and
> Strict DoT servers so applications that might want to dynamically
> discover such encrypted services are not able to. At the time of
> writing, efforts to provide standardized signalling mechanisms for
> applications to also discover the services offered by local
> resolvers are in progress
> [I-D.ietf-dnsop-resolver-information]. Note that an increasing
> numbers of ISPs are deploying encrypted DNS, for example see the
> Encrypted DNS Deployment Initiative [EDDI]."

I disagree with this text, since it seems to imply that a discovery
mechanism would be a good thing. I suggest instead that any discovery
mechanism threatens the goal of DoE (DNS over Encryption) since it
could be easily used to direct users to a resolver which they disagree
with (for the same reason, DoH on Internet Access Providers is not
very interesting since, if you trust your access provider, you don't
really need DoE).

The point of DoE is to be able to have a secure link to the resolver
you decided to trust. If we are to mention discovery, I demand that
the text should be more neutral, not implying that we are missing
something.