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

Rob Sayre <sayrer@gmail.com> Wed, 31 March 2021 21:28 UTC

Return-Path: <sayrer@gmail.com>
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 C55B83A37DC for <dns-privacy@ietfa.amsl.com>; Wed, 31 Mar 2021 14:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (2048-bit key) header.d=gmail.com
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 J7cgFbV8ne5q for <dns-privacy@ietfa.amsl.com>; Wed, 31 Mar 2021 14:28:32 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35EC3A37DB for <dprive@ietf.org>; Wed, 31 Mar 2021 14:28:31 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id ce10so32223951ejb.6 for <dprive@ietf.org>; Wed, 31 Mar 2021 14:28:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hgSeJVC3ReGD+S1awN4yqIFH2yJZWVzNvIyKDixQCeU=; b=rhxplfDcL5UbxQPuYIszhibZ0qlljnlUo57dWPF2D4q8/r7ftXyT5Zx7BK8VvW0G0G G6LjXw1JT0r9WDREVCFVPMxLKfKB5sGRhGHHCiZaq/1EnbbdhBslcHRQWcIDfEdafsZT gxzjt+FRDEN9nPaaYYic71U2Rt+3qW8BO8kEj/FiT5fr8/Hc6LZWDXkdN/lYFxi6t+8a 05A80vCsA/fX8PawugfsRP3PjLx1n3YbZuLD/bq6gk0xxzxYQPN2FjWbJ9J3uxSROUwV YnKpwgGsPa8wjJtzM+jdXzNN84uRzpnHYHMEj+cL6G2e143cNgMLXPtyd4N7lmRsBq7G xwLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hgSeJVC3ReGD+S1awN4yqIFH2yJZWVzNvIyKDixQCeU=; b=M0F6f+aRhThbg+g5AFGIgReE/vA1+uM5yycB1QWpe6NT4f0vD2N53JjMTOGixoQoQc PMFe7BBsorI3T4F876QQZ+6+ojc1B/EB4R1Y5U9RWCiHHGRPhxVv081gX1vVtIQgC1n5 oOdA/9p3RGK9TWOt3gUdKmT08DBkVnnhJYMzOqzyx1yREUZ5cEqe4UhcWeNy6dxYGdz0 RCE1xJR8CZaiaSsRr3c/cakVTy4R+dwGlGLpxheFCQvIJ30lWUtlve2FKaw2wTnhgsIY Mh2aAcfzF8qlwemqJoVpvqvVMB1fuTTnxaupHfhvD7+voFqIbcYI7zh37B1smT0/R1XT 7ZSQ==
X-Gm-Message-State: AOAM533GaE8B6xFnTROP7RiakzbKYOSFU3+fghZquDwi/MqtJVX3fxvR 39GHsUKpI7/SPxEYfBxteTMh6p1TdNdewWfUuhqHqp0E8SOVQA==
X-Google-Smtp-Source: ABdhPJxnXVeWRU7sNDYFepLKpTMZmmTZakkHj3oLgD7EjAdtGk81RoGx46eiXN5/HmAiHir18ZLMW0AUQxNlvc++v5Q=
X-Received: by 2002:a17:906:6817:: with SMTP id k23mr5724024ejr.6.1617226104986; Wed, 31 Mar 2021 14:28:24 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <4B1CCB51-C777-4434-B28E-76C22C12E4DA@pch.net>
From: Rob Sayre <sayrer@gmail.com>
Date: Wed, 31 Mar 2021 14:28:13 -0700
Message-ID: <CAChr6Sym=tm-vj-3FB-GbOG6U=U4CFsRE6yyWJk14waZQLbRiQ@mail.gmail.com>
To: Bill Woodcock <woody@pch.net>
Cc: "dprive@ietf.org" <dprive@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008261bf05bedbcbef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/UvHI4B0cGcjDVzf9Fb7aUr570zg>
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:28:37 -0000

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.


>
> > 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?
>

I think the idea is roughly that DoT/DoQ will just reinvent what's in DoH,
but without as much support and reuse. Here's Mozilla's latest numbers on
DoH:
https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-https-doh-update-recent-testing-results-and-next-steps/
(yes, it's latency)


>
> >> 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?
>

In that case, I think the goal would be to prevent aggregate measurements,
rather than individual data.

thanks,
Rob