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

Christian Huitema <huitema@huitema.net> Thu, 01 April 2021 05:43 UTC

Return-Path: <huitema@huitema.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 68AA63A11D4 for <dns-privacy@ietfa.amsl.com>; Wed, 31 Mar 2021 22:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 DXaH_O1XCDIB for <dns-privacy@ietfa.amsl.com>; Wed, 31 Mar 2021 22:43:46 -0700 (PDT)
Received: from mx36-out20.antispamcloud.com (mx36-out20.antispamcloud.com [209.126.121.68]) (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 5AA933A11D1 for <dprive@ietf.org>; Wed, 31 Mar 2021 22:43:46 -0700 (PDT)
Received: from xse28.mail2web.com ([66.113.196.28] helo=xse.mail2web.com) by mx134.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1lRq7K-0018kL-0S for dprive@ietf.org; Thu, 01 Apr 2021 07:43:44 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4F9sYS5qd1z4cCX for <dprive@ietf.org>; Wed, 31 Mar 2021 22:43:40 -0700 (PDT)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1lRq7I-0005wL-M6 for dprive@ietf.org; Wed, 31 Mar 2021 22:43:40 -0700
Received: (qmail 478 invoked from network); 1 Apr 2021 05:43:40 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.58.43.102]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dprive@ietf.org>; 1 Apr 2021 05:43:40 -0000
To: Bill Woodcock <woody@pch.net>, Rob Sayre <sayrer@gmail.com>
Cc: "dprive@ietf.org" <dprive@ietf.org>
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> <4B1CCB51-C777-4434-B28E-76C22C12E4DA@pch.net>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <ccd66dc4-b58e-917b-2d5f-6e732b5add65@huitema.net>
Date: Wed, 31 Mar 2021 22:43:40 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <4B1CCB51-C777-4434-B28E-76C22C12E4DA@pch.net>
Content-Type: multipart/alternative; boundary="------------31504943293C378B0122CE04"
Content-Language: en-US
X-Originating-IP: 66.113.196.28
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wwIbsUgx3VwKj5vUcMDcmx42UuDhyzVYcwl2RB+0AaevkB nb0sL7z0nzNnHN/mXjUh55uqY3MhMgFAHq5BxPxPXn36fLqvhISQ5ykyqUZqUd1jhnM/Mbva2XLV /LIEzaL2KoAZhJekBPedneT7f69902tJZdbQQpVL7A8ejel8VYPAgTtUp75uqlx0KezvZHWhWQ59 Qnb1f8O4K9KHPb6BWQaaSSaRcFTFxaRvADgOuFdAU5fRzM/QzQW9/IoH33AG8ECuCwECazCwODtO F78PiyQEs+dlGXUJLWZ+Gc08Nmllke3azHdKmySKNUVQl4ntlVxnbS8qIO7oudHyb2T1VQ58xe/l rqiRGalI3YPsxOTrFXToVyBmRCgQVX6zVyFUu8qzeMQP6uTHL0d9UjfY+eX5ZvcELCIKs663F/co VFYFvf25LVONYbYifH5OzZDcG6hsRQZiAIgw+z837AqgX7ewI8e1h7RITgN14BHmGVt/ReJ9Mfhz zmbKTH7wI9GEU1utNskUAORCV2WFZX0juPh8WNrp6UcEFtxxstnQGF7lLXQUcNAszDsnoUOr0Bit l3EP++ioG1esCbYLuSfzOI+gTB/pfSlbi1HgG7umZzYYs4qkxKLSV4C340uY5KqGbN7BITAZon7Z Iz1ONK9yUo4/+EUytKrR9Md9I2Rs11ofyiRzagTIpbBAcoLXNTKC1AI9a3irbifzymzQYX+Pcxfb HC5+GO/iJJDm1/PYmutqU6CDzkQ33pqCnw3x4xkM0rNJQGzebnTLunTUqZa61EJi+az4VfKhyoQl HHsBsTcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/fzyAiMohRsAXMXIJir_iC7bEVCA>
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: Thu, 01 Apr 2021 05:43:51 -0000

On 3/31/2021 2:15 PM, Bill Woodcock wrote:
>>> 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.

I think that's the big motivation behind DoQ. Because QUIC runs over 
UDP, it makes some things easier than TCP. In particular, I have seen 
(and done) demos of supporting 50,000 QUIC connections over a single UDP 
socket, which is definitely easier on the system than trying to support 
parallel wait on 50,000 TCP sockets. But this is a motivation to do work 
on the subject, not a recommendation to change the way root servers 
operate. I personally agree with the statement that root servers should 
not rush to implement, but rather wait and see until the technology matures.

-- Christian Huitema