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

Petr Špaček <pspacek@isc.org> Thu, 01 April 2021 12:04 UTC

Return-Path: <pspacek@isc.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 867773A0CBD for <dns-privacy@ietfa.amsl.com>; Thu, 1 Apr 2021 05:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=Yc4BLoSI; dkim=pass (1024-bit key) header.d=isc.org header.b=TO/54Xf9
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 6CSZ4ni-Ibdx for <dns-privacy@ietfa.amsl.com>; Thu, 1 Apr 2021 05:04:38 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 5075F3A0CBA for <dprive@ietf.org>; Thu, 1 Apr 2021 05:04:38 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 6C4C13AB020; Thu, 1 Apr 2021 12:04:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1617278676; bh=MHQh7jpPw1ouqdrWdjFkaC00Kgc5i5cdfN1t3gzDCKw=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=Yc4BLoSI5dpHKnl/izp4JDKL3YmJ0egkK8kgEm0TyI1MTJskIUxLI32Mu/6H+/YZH GMgCD4eycli9dDxl//x+09Ckq94nlMe5wTU3Sb7o+fApyfhiYTrZFVfw7USMhClHbi BkyMgVsSAwfU/D/uwRUc2iWBVJqz8UutesMefS3o=
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 39929160047; Thu, 1 Apr 2021 12:04:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F15191600AA; Thu, 1 Apr 2021 12:04:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org F15191600AA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1617278676; bh=pAL4FH2G4+fWNamyg+ZhmKRu38rsp5nnvG7IAnufCdw=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=TO/54Xf9s6fn2fJwZM1MCjwLipTAWiROnALpxn0UqCG9I06Cd/VENcYluKVU+uDKL QOUdzqZnEFFg2iaxxrAnFzpvnzRFfffE182u0wK+G9QiG4J1J7L1rvbJmP4KyO1Utk +u6tX71Ry6attharekp8APmCKFgqSl+bBkJHN2NE=
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CHQW6LABQKLD; Thu, 1 Apr 2021 12:04:35 +0000 (UTC)
Received: from [192.168.0.122] (ip-86-49-243-175.net.upcbroadband.cz [86.49.243.175]) by zmx1.isc.org (Postfix) with ESMTPSA id 7A079160047; Thu, 1 Apr 2021 12:04:34 +0000 (UTC)
To: Tomas Krizek <tomas.krizek@nic.cz>, Rob Sayre <sayrer@gmail.com>, Bill Woodcock <woody@pch.net>
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> <CAChr6Sym=tm-vj-3FB-GbOG6U=U4CFsRE6yyWJk14waZQLbRiQ@mail.gmail.com> <62d91128-6ef7-1a92-1ac8-f67e6af90583@nic.cz>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <pspacek@isc.org>
Message-ID: <c6a16f67-f73c-6c98-dad2-f97c182aa50a@isc.org>
Date: Thu, 1 Apr 2021 14:04:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <62d91128-6ef7-1a92-1ac8-f67e6af90583@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/eEAcztkwMibFfLRQb_gW--Uu34M>
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 12:04:44 -0000

On 01. 04. 21 11:59, Tomas Krizek wrote:
> On 31/03/2021 23.28, Rob Sayre wrote:
>> On Wed, Mar 31, 2021 at 2:16 PM Bill Woodcock <woody@pch.net> wrote:
>>
>>>
>>> …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.
>>>
>>
>> Plenty of folks have evaluated the costs here. I'd prefer to discuss data
>> rather than "checking with engineers". It's not really reasonable to
>> measure "server load per-query" without a bunch of other data on how the
>> TLS sessions are being created and maintained.
>>
>> So, if you have some data you'd like to share with the list, that would
> be
>> most welcome.
> 
> We've done some measurements comparing the server-load overhead of DoT
> and DoH and while the exact results vary greatly with the client
> behaviour, connection management and other parameters, I think 3x-5x
> server-load overhead (compared to UDP) is a reasonable expectation. [1]

I will add couple more details about these measurements:

Data show that TLS algorithms in use *and* connection reuse parameters 
are crucial. Well-behaved clients over DoT with P256 certificate can be 
"only" ~ 2.9 x more expensive (on server) than plain UDP, thanks to the 
fact that TCP+TLS connection setup costs get amortized for longer 
connections.

For well-behaved clients who do not keep idle connections open the cost 
jumps up to 10x.

To generalize for the root server scenario, we need to consider that a 
particular well-behaved client should contact root servers rarely, which 
means that connection reuse is unlikely. For this reason, I believe that 
costs on the server side are likely to be closer to the 10x mark for CPU 
costs.

There are limitations to this measurement and generalization, however:
- Measured on stub<->recursive so the generalization might not apply, 
especially if recursive<->root has much better connection reuse 
conditions (seems extremely unlikely to me)
- No information about bandwidth
- No information about latency
- No information about memory consumption
- No information about DoS potential - we measured well-behaved clients

Petr Špaček  @  ISC

> Our measurements were for resolvers, but the same methodology and tool
> could also used for authoritative server measurements.
> 
>  From latency point of view, it again depends on connection management
> etc., but inevitably, some queries will have the additional cost of
> establishing a TCP/TLS handshake. If anyone's interested in measuring
> the impact in various network conditions, it's possible to simulate
> latency with kernels' Network Emulator [2]. When we've tried that, the
> results looked as I've described [3], but the exact outcome depends on
> many variables.
> 
> [1] - https://indico.dns-oarc.net/event/34/contributions/782/
> [2] -
> https://dns-shotgun.readthedocs.io/en/stable/replaying-traffic/#emulating-link-latency
> [3] - https://dns-shotgun.readthedocs.io/en/stable/latency-histogram