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

Peter Koch <pk@DENIC.DE> Wed, 07 October 2020 21:16 UTC

Return-Path: <pk@DENIC.DE>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 637E93A13D3; Wed, 7 Oct 2020 14:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, 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 ajCDYfDS780s; Wed, 7 Oct 2020 14:16:24 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2050:101:465::110]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E1AE3A13D0; Wed, 7 Oct 2020 14:16:24 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 4C66Zt06ndzQlHP; Wed, 7 Oct 2020 23:16:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=MBO0001; t=1602105379; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bbUl0wLQrNfCiEhZjhg/ARguCNdTTI/VXCcCH6EUFy4=; b=f8bwVkahPMktaeXku7GOHzT++qIzk8YyFeSr/5RZFfvsZRb6PItr98Ph9dF1gebjmIofxi 8CLlgrCzPoubR5hcd/EQcc1mLxXHPkUINX8y7jVWzJEoEkcFJgsDvuYe426SK65Ph8R32P i0U8UbfNYcFXBKYC/ff4Rk6kLY9YEOWsrbeiex0cwLLBs25JUcuqH7umBmsfj/hGGCsmzo uD/oT+ykl0aLZ36rKtrK6lvwI5hEGsPTs1iJqYyN4RbC+7VROhCb5/KCrBwoXXllQqvRJr DAY8r/pXluGrnW9g0P8VKejn7BYaWBXe3X7kCodx9uz/8X7KpCOvrsMHhozXsQ==
Received: from ([]) by ( []) (amavisd-new, port 10030) with ESMTP id bWHswtCBCN_I; Wed, 7 Oct 2020 23:16:18 +0200 (CEST)
Date: Wed, 7 Oct 2020 23:16:15 +0200
From: Peter Koch <pk@DENIC.DE>
To: Warren Kumari <>
Cc: Brian Haberman <>,,, The IESG <>,
Message-ID: <>
Mail-Followup-To: Warren Kumari <>, Brian Haberman <>,,, The IESG <>,
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Rspamd-Score: -7.11 / 15.00 / 15.00
X-Rspamd-Queue-Id: 60A9416A5
X-Rspamd-UID: 34385f
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 21:16:26 -0000

Hi Warren,

On Wed, Oct 07, 2020 at 04:39:54PM -0400, Warren Kumari wrote:

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

I think this text is mixing too many aspects that are (or should eventually be)
covered in other parts of the document.  The antipodes are _not_ 'public'
and 'secret'.  The purpose of that section was to exactly counter the
too narrow perception that 'all data in the DNS is public' (which by the
way, was a usual counter argument to NSEC3) to help motivate the need
for further dealing with DNS privacy.  It does not suggest to store secrets
in the DNS.  The original text, I believe - biased as might be - did and does clearly
differentiate betweeen residual data and transactions.  'passive DNS'
is not a feature of the DNS - it is a by-product and, from the perspective
of privacy, to be addressed under 'risks'.