[Int-dir] Intdir telechat review of draft-ietf-dnsop-rfc7816bis-10

Jean-Michel Combes via Datatracker <noreply@ietf.org> Fri, 20 August 2021 20:12 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: int-dir@ietf.org
Delivered-To: int-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EBE3A0B84; Fri, 20 Aug 2021 13:12:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Jean-Michel Combes via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: dnsop@ietf.org, draft-ietf-dnsop-rfc7816bis.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162949032426.20576.2607114366091311647@ietfa.amsl.com>
Reply-To: Jean-Michel Combes <jeanmichel.combes@gmail.com>
Date: Fri, 20 Aug 2021 13:12:04 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/zaJO0vt9ix9vZ3o54Nfug26lk6U>
Subject: [Int-dir] Intdir telechat review of draft-ietf-dnsop-rfc7816bis-10
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Aug 2021 20:12:05 -0000

Reviewer: Jean-Michel Combes
Review result: Ready with Nits

Hi,

Please find my review, as member of the INT Area Directorate, of the following
document:

<review>

             DNS Query Name Minimisation to Improve Privacy
                     draft-ietf-dnsop-rfc7816bis-10

<snip>

1.  Introduction and Background

   The problem statement for this document is described in [RFC7626].

<JMC>
s/[RFC7626]/[RFC9076]
</JMC>

<snip>

1.1.  Experience From RFC 7816

   This document obsoletes [RFC7816].  RFC 7816 was labelled
   "experimental", but ideas from it were widely deployed since its
   publication.  Many resolver implementations now support QNAME
   minimisation.  The lessons learned from implementing QNAME
   minimisation were used to create this new revision.

<JMC>
Maybe, another argument to move to “Standards Track”:
For the moment, Root Server Operators do not feel comfortable with
authoritative DNS encryption. They encourage the increased deployment of QNAME
minimisation [REF_informative].

[REF_informative]
https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf </JMC>

<snip>

5.  Performance Considerations

<snip>

   QNAME minimisation can increase the number of queries based on the
   incoming QNAME.  This is described in Section 2.3.  As described in
   [devries-qnamemin], QNAME minimisation in strict mode both increases
   the number of DNS lookups by up to 26% and leads to up to 5% more
   failed lookups.  The full cache in a production resolver will soften
   that overhead.

<JMC>
I didn’t find any definition/explanation about “strict mode” of QNAME
minimization inside this document. There is no definition/explanation about
strict (and relaxed) mode(s) inside [devries-qnamemin] too. So, I don’t
understand how is useful this paragraph for the document. May you clarify this
point, please? </JMC>

6.  Security Considerations

   QNAME minimisation's benefits are clear in the case where you want to
   decrease exposure to the authoritative name server.  But minimising
   the amount of data sent also, in part, addresses the case of a wire
   sniffer as well as the case of privacy invasion by the servers.
   (Encryption is of course a better defense against wire sniffers, but,
   unlike QNAME minimisation, it changes the protocol and cannot be
   deployed unilaterally.  Also, the effect of QNAME minimisation on
   wire sniffers depends on whether the sniffer is on the DNS path.)

<JMC>
Maybe, my comment about Root Servers Operators (cf. Section 1.1) may be used to
illustrate the difficulty to deploy encryption everywhere. </JMC>

<snip>
</review>

Thanks in advance for your replies.

Best regards,

JMC.