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>
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 637E93A13D3; Wed, 7 Oct 2020 14:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denic.de
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 ajCDYfDS780s; Wed, 7 Oct 2020 14:16:24 -0700 (PDT)
Received: from mout-b-110.mailbox.org (mout-b-110.mailbox.org [IPv6:2001:67c:2050:101:465::110]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1AE3A13D0; Wed, 7 Oct 2020 14:16:24 -0700 (PDT)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [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 mout-b-110.mailbox.org (Postfix) with ESMTPS id 4C66Zt06ndzQlHP; Wed, 7 Oct 2020 23:16:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at heinlein-support.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; 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 smtp2.mailbox.org ([80.241.60.241]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (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 <warren@kumari.net>
Cc: Brian Haberman <brian@innovationslab.net>, dns-privacy@ietf.org, dprive-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-dprive-rfc7626-bis@ietf.org
Message-ID: <20201007211615.GV956@denic.de>
Mail-Followup-To: Warren Kumari <warren@kumari.net>, Brian Haberman <brian@innovationslab.net>, dns-privacy@ietf.org, dprive-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-dprive-rfc7626-bis@ietf.org
References: <160193413191.28964.1483642169279931217@ietfa.amsl.com> <59635c3f-e291-02bc-06a8-cbef46e38361@innovationslab.net> <CAHw9_iL8eq+sLXJaDLD9qzyk9CFhTcuKpC8D+LvAHZLdd2-MOg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHw9_iL8eq+sLXJaDLD9qzyk9CFhTcuKpC8D+LvAHZLdd2-MOg@mail.gmail.com>
X-MBO-SPAM-Probability:
X-Rspamd-Score: -7.11 / 15.00 / 15.00
X-Rspamd-Queue-Id: 60A9416A5
X-Rspamd-UID: 34385f
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/g-_pMiJ4LcP-o1wAMTw7W5zjhAM>
Subject: Re: [dns-privacy] Warren Kumari's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)
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, 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'.

-Peter