Re: [dns-privacy] Warren Kumari's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)

Warren Kumari <> Wed, 07 October 2020 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D59C3A1370 for <>; Wed, 7 Oct 2020 13:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bvIX-hI4fIor for <>; Wed, 7 Oct 2020 13:40:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3270D3A136D for <>; Wed, 7 Oct 2020 13:40:34 -0700 (PDT)
Received: by with SMTP id r127so3854562lff.12 for <>; Wed, 07 Oct 2020 13:40:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MU/WO0WoNjjjpK7aZutkhkX215h3wj65Qr7ZDDE9ShY=; b=Hm8iVLMs/gz1KxWVKtUGuN8wG/pA414raF8OnM6XMpaOoX+l/lctc5xD+TMySeD2wS QZUUbiVSPD6n6WclwbtmOAHMb6f4KSI9P0bmCm3qwkY4EhNv2eAdggsJLREM7zwfNSpe NF8sKjODVP9zBTw4UDLodCdViPU3e1JQNVr+7kfyYlJDBbcPYAY3GlUT4ZprTEhrZvFd +jpVLpqTFrVDModmOsboROJjSutcrbMYfpNSKqeEUDLSIxreNEIs7IfagkCeOIetxMwD oFM43qTGST4Vq/5E6JSJTvgPkJTh0mFXNqKIYkaz7TZe3jWEIJPTrBqLrqwnuQsGoZhi KyiQ==
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=MU/WO0WoNjjjpK7aZutkhkX215h3wj65Qr7ZDDE9ShY=; b=iCZ3OnR4ff26HQuLwf3UhcF4mLGSDwj7OmtXWRwezy0ggXtzm9En3PZEKavyUxmJl5 aMTad1tTtDGmstG7QwJpCSTUi3R0CFsWPlXjbl9Ou+DeXW0bCqHrGECj/be4TjKjErDH dK8m+gUP+9fof/GfMIEC5eEl6XRpMV2xUYdGalSst5vRLRVvTWW+9uDsOBrk5rnajKIU nOhyWsImF/V1XDeY5ZrMjzqEQOcYS0yolCrGw+aegnwnqBrY7ETSlu1WgvJaWCzDzNC6 kzm5YoLWj6+I0J/LD0S0iCWWM2KbnmRJHTIvL5i24fLvsiRC8b+HQhWUXxaHuLEP9dnA d9JA==
X-Gm-Message-State: AOAM532Z6EwshkfaTNOR4od0JEYYKyntFiGdISYJB0rlZuYfqnZwcffL oWuia7oFQn1FNUCHoQOf9fQWInlsAnEWIZAEJn0o1g==
X-Google-Smtp-Source: ABdhPJxDmgdI3Z/3Za7LatZpH+MNVyAfGQ3N16g6NiCRQW/MANPKd3D6dpD2H7fdJ9WhUjgeOy9PIi9xR0S9EU/MWrU=
X-Received: by 2002:a19:ad08:: with SMTP id t8mr1458777lfc.41.1602103232552; Wed, 07 Oct 2020 13:40:32 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Wed, 7 Oct 2020 16:39:54 -0400
Message-ID: <>
To: Brian Haberman <>
Cc: The IESG <>,,,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [dns-privacy] Warren Kumari's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)
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, 07 Oct 2020 20:40:37 -0000

On Wed, Oct 7, 2020 at 3:29 PM Brian Haberman <> wrote:
> Hi Warren,
>      Thanks for the feedback. I have a couple of responses (as document
> shepherd) inline...
> On 10/5/20 5:42 PM, Warren Kumari via Datatracker wrote:
> > Warren Kumari has entered the following ballot position for
> > draft-ietf-dprive-rfc7626-bis-06: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > Apologies for changing my YES to a DISCUSS -- I found a later version of my
> > notes on this draft.
> >
> > My DISCUS is specifically around the"The Alleged Public Nature of DNS Data" /
> > "It has long been claimed that "the data in the DNS is public" section -- it
> > seems to be unnecessarily creating and then shooting down a strawman. The "the
> > data in the DNS is public" aphorism talks is more about the confidentiality one
> > can expect **publishing** data in the DNS, not the privacy of the lookups.
> > This whole section (to my mind) undersells the threat that publishing something
> > in the DNS and expecting it to remain private creates -- for example, I'd be
> > extremely foolish to insert: 600 IN TXT
> > "Hunter2"
> >
> > Services like Farsight Securities (excellent!) DNSDB will likely capture this
> > almost as soon as I use it somewhere. In addition, the "Due to the lack of
> > search capabilities, only a given QNAME will reveal the resource records
> > associated with that name" sentence is either false, or at the very least,
> > misleading.
> The above is an excellent example of the subtle difference between DNS
> publication privacy and DNS transaction privacy. DNSDB only know the
> domain name because the DNS transaction is not encrypted.
> The goal of this section, going back to 7626, is to point out that
> difference. I believe you agree with that given your support for the
> second paragraph in the section.
> >
> > $ dig +dnssec | grep NSEC
> > clearly tells me that the names and both exist,
> > and $ dig +dnssec | grep NSEC tells me that the next name is
> >
> >
> Sure, if a zone operator leverages NSEC records, the above could happen.
> If a zone operator does not want that type of enumeration to occur,
> NSEC3 records should be used.
> Is the ask here for some description of possible means of enumerating a
> zone if NSEC records are published? Or that Passive DNS allows observers
> to collect names if a collector is in the DNS exchange path? That seems
> like overkill to me given that the enumeration can only occur in very
> specific instances.

I think that much of what is making me twitch is the tone in this
section -- the section title is: "The *Alleged* Public Nature of DNS
Data" (emphasis mine) and the first sentence is: "It has long been
claimed that "the data in the DNS is public"."; both of these imply
that data in the DNS should not be thought of as (generally) public,
or that it is generally feasible to keep DNS data private.  I think
that this is likely to lead to people thinking that putting
super-secret stuff in the DNS will end well for them. There are all
sorts of ways that this leaks, including NSEC zone walking, people
looking up at work, and then taking
their laptop home, opening it and having the browser reload the page,
search-list magic, passive-dns, etc.

How is something like (will need massaging):

4.1.  The Public Nature of DNS Data

   It is often stated that "the data in the DNS is public".  This sentence
   makes sense for an Internet-wide lookup system,  and there
   are multiple facets to the data and metadata involved that deserve a
   more detailed look.  First, access control lists (ACLs) and private
   namespaces notwithstanding, the DNS operates under the assumption
   that public-facing authoritative name servers will respond to "usual"
   DNS queries for any zone they are authoritative for without further
   authentication or authorization of the client (resolver).  Due to the
   lack of search capabilities, only a given QNAME will reveal the
   resource records associated with that name (or that name's non-
   existence).  In other words: one needs to know what to ask for, in
   order to receive a response. However, there are many ways in
   in which supposed "private" resources leak, including DNSSEC
  NSEC zone walking [REF]; passive-DNS services [ref]; employees
  taking their laptops home (where they may use a different resolver),
  and refreshing names which should only exist in their enterprise
environment, etc.

The zone transfer QTYPE [RFC5936] is
   often blocked or restricted to authenticated/authorized access to
   enforce this difference (and maybe for other reasons).

   Another differentiation to be considered is between the DNS data
   itself and a particular transaction (i.e., a DNS name lookup).  DNS
   data and the results of a DNS query are public, within the boundaries
   described above, and may not have any confidentiality requirements.
   However, the same is not true of a single transaction or a sequence
   of transactions; those transaction are not / should not be public.  A
   single transactions reveals both the originator of the query and the
   query contents which potentially leaks sensitive information about a
   specific user.  A typical example from outside the DNS world is: the
   web site of Alcoholics Anonymous is public; the fact that you visit
   it should not be.  Furthermore, the ability to link queries reveals
   information about individual use patterns.

I really like the AA example (and most of the second paragraph), but
I've seen many many instances where someone puts something like or
in the DNS, and then are dismayed to discover that people have found
it... (and yes, the NOC was well aware of this when putting it in the
DNS, but it made a nice example)
I really don't want us to be reinforcing the idea that the obscurity
from "unguessable" names or split-zone will provide people with actual

> Regards,
> Brian

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.