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

Warren Kumari <warren@kumari.net> Thu, 08 October 2020 00:16 UTC

Return-Path: <warren@kumari.net>
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 3F7813A0A5E for <dns-privacy@ietfa.amsl.com>; Wed, 7 Oct 2020 17:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 PGtInW74saop for <dns-privacy@ietfa.amsl.com>; Wed, 7 Oct 2020 17:16:53 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 92F673A0A42 for <dns-privacy@ietf.org>; Wed, 7 Oct 2020 17:16:53 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id m16so3833266ljo.6 for <dns-privacy@ietf.org>; Wed, 07 Oct 2020 17:16:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=xcMS27dGtCa974fBTkkjEMh5JI6xiCsTqt1kQkoVNHc=; b=gXXMPdvhGqPjUfifPhEpQozWCA5e9y6NU7GfVlb86Es4DHojZe5+agcHEtYCJlBLBk NYwK1sDUoUnNJCbE0Gse3YGGZwyaZxv1njH+n55Kz2oP/jYLqGHJRoRIhHREOYEnwvTY JOet3acc83NFK8OKDultz+9R3FWA1kC/TQnx4/qYx5ky1GmFOhgBH4UzghYc+hDC8A/3 cAZ+gEuyOVkk8uUJcnbWqkGHZlo3FrT1ToZbYeH6D4m4WyUT+okkMcuan01OeWiehZJ/ /R2IxrXE0QBMjJubfUGLGWmQRfGaLsXtbK0j3BMPlkiATTqr5fCIB8jUCOXXOj/txEiR qLrA==
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; bh=xcMS27dGtCa974fBTkkjEMh5JI6xiCsTqt1kQkoVNHc=; b=NmIG5Kj+MALwL0Zd7IxHOWoZbgUeyMjldIAcjQxv2Ag1XXYivk187V3vw3bExYScaA LKEeSJqHef3gLtshLnRygLwtJ3lXMgERXEr9AsZbdjEm5z++W5jsgr9lYNFFqgbp2180 FnigpwQz5bdVf2+EtmcUta8FthacBMR+sQtQ6edYtxfOpSWz4WA77Nbt6HqseZGU0jy6 EN5EZN/HnrzN4pibw2ngnrtJ1N4RFSazVHH1haaLX/SUezjn8TqkmHUiDzhej+Gxk1Cv HWFbb6okq64tubqXGk/7ImUvFDNZHxFY1avnspDPtOhfa8Y9i8sK0LEGrvoB3OTNhB1j QHHw==
X-Gm-Message-State: AOAM533Ff4eyUwub5laChLBuGdCoyGD2PGKZ1Yr1RxLXtUBoVIzy62XD iM4u08/CyBSiMrTe8VBoSgKjYKgdNLV/l9rL9LA7YA==
X-Google-Smtp-Source: ABdhPJyTsJ/tuQHNvOTxvRFNJqhKk8NlY+cGiNNNUdkJiXkx8Qr89QpOPNEHzrCnrcT5U6kGsp4zcZeyxv5I0tgjM/E=
X-Received: by 2002:a05:651c:510:: with SMTP id o16mr1911417ljp.79.1602116211388; Wed, 07 Oct 2020 17:16:51 -0700 (PDT)
MIME-Version: 1.0
References: <160193413191.28964.1483642169279931217@ietfa.amsl.com> <59635c3f-e291-02bc-06a8-cbef46e38361@innovationslab.net> <CAHw9_iL8eq+sLXJaDLD9qzyk9CFhTcuKpC8D+LvAHZLdd2-MOg@mail.gmail.com> <20201007211615.GV956@denic.de>
In-Reply-To: <20201007211615.GV956@denic.de>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 7 Oct 2020 20:16:14 -0400
Message-ID: <CAHw9_iJa+-e9uP78yX+_pj0FUd94MTue6No7MPBGE3EAAcADtg@mail.gmail.com>
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
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/vWa4MuxNV_lmwqEGz6_E0aF4BNE>
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: Thu, 08 Oct 2020 00:16:55 -0000

On Wed, Oct 7, 2020 at 5:16 PM Peter Koch <pk@denic.de> wrote:
>
> 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 document is in IESG eval -- there is no more "eventually".


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

I fully agree that we need to explain the need for DNS privacy -- but
to my mind the original text does the opposite - it provides the
illusion that you can put private info in the DNS and (realistically)
expect it to stay that way. I fully agree with your below that things
like passive dns is not a feature of the DNS, but it *is* a way that
records that people might assume to be private leak.

Yes, I do fully understand that the primary purpose of this is to
discuss the privacy needs / implications of leaking in *transactions*,
but this section seems to pooh-pooh the risks of exposing "private"
names...


Tim's suggestion (coupled with changing the section title) would be
fine with me...

W

> 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



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