Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

Bill Woodcock <woody@pch.net> Wed, 31 March 2021 21:16 UTC

Return-Path: <woody@pch.net>
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 12A683A3790 for <dns-privacy@ietfa.amsl.com>; Wed, 31 Mar 2021 14:16:18 -0700 (PDT)
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, SPF_PASS=-0.001, URIBL_BLOCKED=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 Lv6yIoiy4-gI for <dns-privacy@ietfa.amsl.com>; Wed, 31 Mar 2021 14:16:13 -0700 (PDT)
Received: from mail.pch.net (keriomail.pch.net [206.220.231.84]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831F43A378F for <dprive@ietf.org>; Wed, 31 Mar 2021 14:16:11 -0700 (PDT)
X-Footer: cGNoLm5ldA==
Received: from [10.19.48.7] ([69.166.14.2]) by mail.pch.net (Kerio Connect 9.2.7 patch 3) with ESMTPS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 31 Mar 2021 14:16:01 -0700
From: Bill Woodcock <woody@pch.net>
Message-Id: <4B1CCB51-C777-4434-B28E-76C22C12E4DA@pch.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_22C540E2-7499-4954-8B51-B2255036FDCD"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Wed, 31 Mar 2021 23:15:53 +0200
In-Reply-To: <CAChr6Szg+EbFqSpFPco8Gyb9pzNNnrSoQJcXTDVeg40_EXiPDg@mail.gmail.com>
Cc: "dprive@ietf.org" <dprive@ietf.org>
To: Rob Sayre <sayrer@gmail.com>
References: <c925da9089fa4b1e991ec74fc9c11e7f@verisign.com> <CAChr6Sxwao=FAcoeHMuOf0L=JCZ+wvhsr9BNZW_dbt+1=HWQwg@mail.gmail.com> <20210331091238.GA10597@nic.fr> <CAChr6SxPNVAZMYfZqF+K6Xf8FPGa9ZgHkL-uUvtKMEiJSPmp8Q@mail.gmail.com> <2607D274-936F-4A31-9E4D-EEBCF45BE838@pch.net> <CAChr6Szg+EbFqSpFPco8Gyb9pzNNnrSoQJcXTDVeg40_EXiPDg@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/gmzyDRYhmXxesgft-s2lMRS7vT4>
Subject: Re: [dns-privacy] Root Server Operators Statement on DNS Encryption
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: Wed, 31 Mar 2021 21:16:18 -0000


> On Mar 31, 2021, at 10:51 PM, Rob Sayre <sayrer@gmail.com> wrote:
> 
> 
> 
> On Wed, Mar 31, 2021 at 1:29 PM Bill Woodcock <woody@pch.net> wrote:
> 
> 
>>> > On Mar 31, 2021, at 9:55 PM, Rob Sayre <sayrer@gmail.com> wrote:
>>> > I still don't understand the resistance here. Some data on what the impact would be still seems like the most helpful thing to move the conversation forward.
>>> 
>> We have that:
>> 
>> https://vaibhavbajpai.com/documents/papers/proceedings/dot-pam-2021.pdf
>> 
> That paper is about home measurements, and says:
> 
> "Previous work [8,17,26] has studied the support and response times of DoT (and DoH). However, the studies performed response time measurements from proxy networks and data centers, which means that results might not appropriately reflect the latency of regular home users...”

…and it’s measuring latency rather than server-side load.  I just checked with our engineers, and it sounds like the server load per-query is more like 3x-5x higher for the encrypted queries.

> only measures DoT, rather than the more popular DoH.

DoH isn’t that much worse than DoT from a load perspective, but it's a web-browser thing…  It’s difficult for me to imagine anyone with enough clue to operate a recursive resolver wanting to use DoH to query an authoritative server.  What would be the point?

>> Could you state the problem that’s being solved?
>> 
> Sure, it's in the first sentence of https://tools.ietf.org/html/draft-ietf-dprive-opportunistic-adotq-00:
> 
> "A recursive resolver using traditional DNS over port 53 may wish instead to use encrypted communication with authoritative servers in order to limit passive snooping of its DNS traffic."

Right, so that just means the wording of the draft is over-broad, in that it just says “authoritative” rather than “authoritative SLD” or something.  It’s quite a stretch to think that anything sensitive would be disclosed between a well-behaved recursive and a _root_ server, since it doesn’t disclose either the individual nor the domain being queried.

So, again, what problem would be solved?

                                -Bill