Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis

Rob Sayre <> Wed, 28 August 2019 03:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3C481200FF for <>; Tue, 27 Aug 2019 20:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1d_kBsNTDKYg for <>; Tue, 27 Aug 2019 20:24:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A7BA120052 for <>; Tue, 27 Aug 2019 20:24:29 -0700 (PDT)
Received: by with SMTP id b10so2992809ioj.2 for <>; Tue, 27 Aug 2019 20:24:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IbLm2f/25Dwc+8/fbygDS2oyI4EEIuiukkjRaajOySk=; b=OBa/uwJQO1/9gbH25oZW/Li8ccOsZtGleeLJds6CtN94Wmcd/VzfbcJcS1QL13fnIw DH+LZZn84GR6b18HHbwHutcigF4JHoA+/48iT/lHIy15m4S4rlh8gNhTPbmWzmBcwYM0 nyIEt+GORGjvYWjyyPzV7jj404CfsPJGRW8XD5ha+D/HveGSXxGK8OZXhRodDwSSmXg+ 1v/flAFNazQU5i3ljT1pcyJ67qKzE6fdwRxPaX7aHV+J526vZN2QbobcReVxi42e4Uon 7fESSnQWw9zV2JxdGOOzMo1yrUP3Qh+zllhl2pxhRxPfjCEdepBWOOEXN4qbAK7WWyvw mykQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IbLm2f/25Dwc+8/fbygDS2oyI4EEIuiukkjRaajOySk=; b=NmG/ksRF1MQFv7JDUqVTepRt5D8d1fuOzNs3K+MpHPMT7RfGwNRB/iWXFHHwymct2P jNgZVt/iEHcYpknbLQ+LXMjHog6UYzE0zagPQhQy11T2ZQUS5OJazTjihdjlFpOA7kyo Bbdfi7jlNIQKyL9dgDdrt+eE4nwn/pOUb3hLnd6vBkFgr2F3n5x3k+tLtzelnw6iw4ms r8p6PFQbgj1ZzqsgzbEWaGksn1D7AbmOfBjAeEawxovS8d+8u1CTE3NtV4efNdvFFukG TtkMbDOYVXstCtB0kMil6IrnTXdJHAeUegLfhXvaeqgMl4FJmTgFtEVvaFYsRn3L2gy/ XBGQ==
X-Gm-Message-State: APjAAAWJUl24pcgcpBo2ZoVXDBIuDAQfmHAtEPwBiSKtRxv+g8A5rGAr 93RqXNjWwq9jSyXa/0GztjeqJW/n5sargoR+HGg=
X-Google-Smtp-Source: APXvYqwU1WqRiXFg+G9dEvfImsRxD+7wa+LG+V2b57l0W6koZDuVtd3IVUqrQea2stbks1arHrXQXB3a45p0f7qodrg=
X-Received: by 2002:a5e:d618:: with SMTP id w24mr1941428iom.73.1566962668584; Tue, 27 Aug 2019 20:24:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Rob Sayre <>
Date: Tue, 27 Aug 2019 20:24:16 -0700
Message-ID: <>
To: "Hollenbeck, Scott" <>
Cc: "" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000003cc766059124ed1c"
Archived-At: <>
Subject: Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Aug 2019 03:24:32 -0000

On Wed, Aug 21, 2019 at 11:22 AM Hollenbeck, Scott <shollenbeck=>; wrote:

> > -----Original Message-----
> >
> > I now read through the whole document,

 I read the whole thing too, and I am confused about three issues.

1) What is the scale of the entire system? As the document states, the
system makes heavy use of caching. But, the queries are simple, so even a
cache miss should be cheap. The traffic to the root servers would seem to
be quite a bit smaller than just Twitter's RPC traffic, going by <>;. To me,
this scale calls into question the extent to which queries need to be
cacheable across requests. I can understand why decisions around these
trade-offs might have been made 20-30 years ago, but it's not clear that
those decisions will remain valid forever.

2) The document states "Some encryption solutions are only designed for
TCP, not UDP." This statement seems a bit imprecise. For example, how does <> fit into this

3) While it's clear the document is focused on the privacy (or,
confidentiality) properties of encrypted transports, and the privacy
implications of the data included in the queries themselves, there seems to
be missing text about the message integrity that encrypted transports