Re: [dns-privacy] Warren Kumari's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)
Warren Kumari <warren@kumari.net> Wed, 07 October 2020 20:40 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 4D59C3A1370 for <dns-privacy@ietfa.amsl.com>; Wed, 7 Oct 2020 13:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
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: 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 bvIX-hI4fIor for <dns-privacy@ietfa.amsl.com>; Wed, 7 Oct 2020 13:40:35 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 3270D3A136D for <dns-privacy@ietf.org>; Wed, 7 Oct 2020 13:40:34 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id r127so3854562lff.12 for <dns-privacy@ietf.org>; Wed, 07 Oct 2020 13:40:34 -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=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; d=1e100.net; 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: <160193413191.28964.1483642169279931217@ietfa.amsl.com> <59635c3f-e291-02bc-06a8-cbef46e38361@innovationslab.net>
In-Reply-To: <59635c3f-e291-02bc-06a8-cbef46e38361@innovationslab.net>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 07 Oct 2020 16:39:54 -0400
Message-ID: <CAHw9_iL8eq+sLXJaDLD9qzyk9CFhTcuKpC8D+LvAHZLdd2-MOg@mail.gmail.com>
To: Brian Haberman <brian@innovationslab.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-rfc7626-bis@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Gu14XOczpzDBcfG_U1S6rONl_fY>
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 20:40:37 -0000
On Wed, Oct 7, 2020 at 3:29 PM Brian Haberman <brian@innovationslab.net> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > 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: my-password-fd345432233e.example.com 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 foo.ietf.org | grep NSEC > > clearly tells me that the names etherpad.ietf.org and ftp.ietf.org both exist, > > and $ dig +dnssec ftpa.ietf.org | grep NSEC tells me that the next name is > > guides.ietf.org.... > > > > 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 secretproject.corp.example.com 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 super-secret-new-product.staging.example.com or ipmi.vm0.noc.ietf.org 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 privacy... > > 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. ---maf
- [dns-privacy] Warren Kumari's Discuss on draft-ie… Warren Kumari via Datatracker
- Re: [dns-privacy] Warren Kumari's Discuss on draf… Brian Haberman
- Re: [dns-privacy] Warren Kumari's Discuss on draf… Warren Kumari
- Re: [dns-privacy] Warren Kumari's Discuss on draf… Tim Wicinski
- Re: [dns-privacy] Warren Kumari's Discuss on draf… Rob Sayre
- Re: [dns-privacy] Warren Kumari's Discuss on draf… Peter Koch
- Re: [dns-privacy] Warren Kumari's Discuss on draf… Warren Kumari
- Re: [dns-privacy] Warren Kumari's Discuss on draf… Rob Sayre
- Re: [dns-privacy] Warren Kumari's Discuss on draf… Tim Wicinski
- Re: [dns-privacy] Warren Kumari's Discuss on draf… Warren Kumari
- Re: [dns-privacy] Warren Kumari's Discuss on draf… Eric Vyncke (evyncke)