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 12:58 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 D94A63A0D96 for <dns-privacy@ietfa.amsl.com>; Thu, 8 Oct 2020 05:58:52 -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=unavailable 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 hrrI3j-AxDi7 for <dns-privacy@ietfa.amsl.com>; Thu, 8 Oct 2020 05:58:50 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 9113B3A0ADF for <dns-privacy@ietf.org>; Thu, 8 Oct 2020 05:58:49 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id a15so5627049ljk.2 for <dns-privacy@ietf.org>; Thu, 08 Oct 2020 05:58:49 -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 :cc; bh=nlRhn7aqrjmHV/8Ra7ZFgTXFbYA8YpjvnPcC7G7Yj1w=; b=DM4MEoVhVBLqi7JflexjlsJAlSGBiuHxSGaF4OAi0q4xpIMw3dlPwgI+PUZYQCG7Cm nqzJ1u1tfbY4tbU6VrftlLHAJ224aVTmEP7xEyT1NB2DjIb6hptAGAavYHGCS68dExNb cMyiNLVEU2bUyhcDeGTkiYFVqIq5a5/3GmWlm8MtV7+eXfSHHE8slB4N7PJtk71dScd5 eaULTJFi1u/APAXDKpJy4oWAXMJlbEagkPVIigiMx5Zfi9ng3ZqVG9p81ZpFaLIW0tCn OxMhSRWlKRly2EBERVX/1tfHeP8BM3i2GuaI/Aw4fQM4X4UG3bodpSvV+Cnlic9U1EJs 3iQQ==
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:cc; bh=nlRhn7aqrjmHV/8Ra7ZFgTXFbYA8YpjvnPcC7G7Yj1w=; b=I1Drks+G1USh3KDDBzVURCUWPs0i+6cj/zwXFHUyQv5lgW6fYdw9xjc2HURaaOVh2Z k1Pp/yeL4QAjtBn5mkkP9sondxPyFFUmgjQIvyRuRZUshq8RmitCGZ4sddGcSytKa6rh 4Ku+/NAQc5KvBmQ9Ib4ldI9APoOgnKry5oFD3cYiJ2jPDEYJ1NAA7+d1I5unJbat/8o7 gwFncYBeH3cS86fi0yEEbYvI0+fpd1pB0zTAw3upm10Y9wQK7yCiMzYdHLNd2otYcr4a gNtsx6MTGAYriunV/CoPfcOTBIy5p8JFFia/+7WDocidtrIbqyCrjaBmw/XSrT/1X04O +d4w==
X-Gm-Message-State: AOAM5331FgJka9wKKgT5iClu83Cnx4WzgV1vRGDdcgDI3CbLkYGNL1Va rhvJLioK3JsK7FZwGFvRY8puE7peoX/lvF3axYNY6g==
X-Google-Smtp-Source: ABdhPJyo8CsyvTdsMoXNl5Su7Y2HhyPvhntXvo8kVMs/pRNkvdMs2qDf8aIpgNKn/3IVKKh1IqLQtfvMHXQW6RvHmic=
X-Received: by 2002:a2e:a374:: with SMTP id i20mr3423406ljn.143.1602161927170; Thu, 08 Oct 2020 05:58:47 -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> <CAHw9_iJa+-e9uP78yX+_pj0FUd94MTue6No7MPBGE3EAAcADtg@mail.gmail.com> <CADyWQ+F5Q1PR825H8eX0woNjosBAYt2QxmrsDR7fzaiWrJZd=w@mail.gmail.com>
In-Reply-To: <CADyWQ+F5Q1PR825H8eX0woNjosBAYt2QxmrsDR7fzaiWrJZd=w@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 8 Oct 2020 08:58:09 -0400
Message-ID: <CAHw9_iLfazXCJABSMpoRzZPR0u=WRzG2HcJqEhGa-kMbZeCk7g@mail.gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: Brian Haberman <brian@innovationslab.net>, DNS Privacy Working Group <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/0DREVbHCp77qfDPoYH7jndtO5LQ>
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 12:58:53 -0000

On Thu, Oct 8, 2020 at 8:51 AM Tim Wicinski <tjw.ietf@gmail.com> wrote:
>
> Warren
>
>    There are many ways in which supposed "private"
>    resources currently leak. A few  examples are  DNSSEC NSEC zone walking;
>    passive-DNS services; etc.
>
> with the references added in. and changing the section title

Thank you very much, that will work for me.
I really do think that this was an important point, and thank you (and
the WG!) for addressing it.

I've just changed my ballot from DISCUSS to YES; it's an important
foundational document, and useful for level-setting.


Thanks again,
W


>
> tim
>
>
> On Wed, Oct 7, 2020 at 8:16 PM Warren Kumari <warren@kumari.net> wrote:
>>
>> 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



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