Re: [dns-privacy] Second Working Group Last Call for draft-ietf-dprive-bcp-op

Stephane Bortzmeyer <bortzmeyer@nic.fr> Fri, 01 November 2019 10:43 UTC

Return-Path: <stephane@sources.org>
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 43A9A120816 for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 03:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qNDGmbCclMOy for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 03:43:09 -0700 (PDT)
Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 2E4CC12008A for <dns-privacy@ietf.org>; Fri, 1 Nov 2019 03:43:09 -0700 (PDT)
Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 9A027A02A0; Fri, 1 Nov 2019 11:43:06 +0100 (CET)
Received: by mail.sources.org (Postfix, from userid 1000) id 725BCC933C; Fri, 1 Nov 2019 11:38:31 +0100 (CET)
Date: Fri, 01 Nov 2019 11:38:31 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: dns-privacy@ietf.org
Message-ID: <20191101103831.GA22563@sources.org>
References: <CADyWQ+GirqA_VKYTAjGpV+aFMQiio2AAqtMX_2SRg45Crpf_-A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADyWQ+GirqA_VKYTAjGpV+aFMQiio2AAqtMX_2SRg45Crpf_-A@mail.gmail.com>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 10.1
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/5getdWzWu8BnNysuuZUBN30_ZqE>
Subject: Re: [dns-privacy] Second Working Group Last Call for draft-ietf-dprive-bcp-op
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: Fri, 01 Nov 2019 10:43:11 -0000

On Thu, Oct 31, 2019 at 11:24:45AM -0400,
 Tim Wicinski <tjw.ietf@gmail.com> wrote 
 a message of 113 lines which said:

> This starts a Second Working Group Last Call for draft-ietf-dprive-bcp-op

Background: I run a small (very small) public DoH and DoT resolver,
and it has a DROP (a policy). If you want to read it, it is only in
french: <https://doh.bortzmeyer.fr/policy>. I checked it against
section 6 and appendix C.

Executive summary: the draft is fine and useful and, IMHO, should be
published.

A few issues:

* the first paragraph of section 4 should be deleted since the draft
does not use RFC2119 (and rightly so), except one lonely SHOULD in
section 5.

* "A DNS privacy service must be engineered for high availability."
I'm not in favor of this sentence. 1) It seems to despise small
resolvers managed by small organisations, while we need many diverse
DoT and DoH resolvers, to avoid centralisation 2) Today, Firefox,
unfortunately, does not allow to add more than one DoH resolver, which
makes the DoH resolver a very critical resource. But I hope that in
the future, we will be able to configure several resolvers, with an
efficient fallback, making the issue of availability less important.

* DROP is not a perfect acronym since the draft does not talk only
about privacy but also about integrity ("result filtering", aka lying
resolvers).

* "exporting DNS traffic from the resolver using e.g. dnstap" May be a
reference to section 6.1.1 about sharing could be a good idea? Today,
many existing policies say things like "we don't store logs for more
than N weeks" but are silent on export/sharing...

* "Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the
number of queries to authoritative servers to increase privacy" RFC
8020 could be mentioned, too, for the same goal.

* Appendix B is really good and useful. "The level of anonymization
this [keeping a /24 for IPv4] produces is perhaps questionable" is
certainly the understatement of the year :-)