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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Mon, 05 Oct 2020 14:42:11 -0700

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.

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

I think that the last 4 or 5 sentences of the section are useful, but that the
rest of the section is actively dangerous as it is likely to be misunderstood.

Please don't misunderstand - I still believe that the document itself is really
important and useful, but the section seems dangerous (and yes, I realize that
it is in RFC7626)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[Edit: I accidentally hit "Send" too early; I have another few comments, also
non-blocking: 1: "Also, sometimes, the QNAME embeds the software one uses,
which could be a privacy issue. For instance,
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org."... Unless you
are a Microsoft or DNS weenie, this is likely not at clear -- what is being
leaked here? The fact that the site uses TCP? LDAP? Windows? Goldbach's
Conjecture? Example software? (I think adding a sentence here would be
helpful...) ]

Thank you for this document - it's really useful, and readable as well.

I do have a few small comments to (possibly) make it even better - I will in no
way be offended if you ignore these...

The background on how DNS works is nicely written, and I'm to point people at
it when I need to explain how the DNS works -- but I think a better name
example than: "What are the SRV records of _xmpp-server._tcp.example.com?"
would be good -- SRV is an unusual record type, and names with underscores
surprise people. I'd instead suggest "What is the MX records for example.com"
or "What is the A record for ftp.example.com?" -- I'm only mentioning this
because the rest of the section is a very general introduction and this might
confuse newcomers...

"At the time of writing, almost all this DNS traffic is currently sent in clear
(i.e., unencrypted). However there is increasing deployment of DNS-over-TLS
(DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in mobile
devices, browsers, and by providers of anycast recursive DNS resolution
services." I think that you might want to remove the "particularly in ..." - I
suspect that it will not age well; the document does say "At the time of
writing" and "increasing", etc., but this document is likely foundational
enough that it will still be referenced many many years from now, and this text
may just cloud matters then.

Whatever the case, thanks again for this document!

---

From: Brian Haberman <[email-masked]>
Date: Wed, 7 Oct 2020 15:29:48 -0400

Hi Warren,
     Thanks for the feedback. I have a couple of responses (as document
shepherd) inline...

> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

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.

> and $ dig +dnssec ftpa.ietf.org | grep NSEC tells me that the next name is

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.

Regards,
Brian

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 Oct 2020 16:39:54 -0400

> like overkill to me given that the enumeration can only occur in very

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

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

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 7 Oct 2020 17:00:16 -0400

Warren

On Wed, Oct 7, 2020 at 4:40 PM Warren Kumari <[email-masked]> wrote:

> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

While the text is OK, what I worry about is that (and we ran into some of
this in the first IESG go round)
was listing everything but everything at this point in time.

Maybe something like

There are many ways in which supposed "private" resources currently leak. A
few
examples are as....   This is not a complete list.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 7 Oct 2020 14:08:45 -0700

> can expect **publishing** data in the DNS, not the privacy of the lookups.

Some discussions I've seen have centered on the idea that resolver
selection in combination with DoH/DoT could lead to the exposure of private
names.

I do not think this is an important issue, but some people clearly do.

thanks,
Rob

---

From: Peter Koch <[email-masked]>
Date: Wed, 7 Oct 2020 23:16:15 +0200

Hi Warren,

>   and refreshing names which should only exist in their enterprise

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 Oct 2020 20:16:14 -0400

On Wed, Oct 7, 2020 at 5:16 PM Peter Koch <[email-masked]> wrote:
> covered in other parts of the document.

The document is in IESG eval -- there is no more "eventually".

> The antipodes are _not_ 'public'
> 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

---

From: Rob Sayre <[email-masked]>
Date: Wed, 7 Oct 2020 17:34:24 -0700

> The document is in IESG eval -- there is no more "eventually".

It can always be obsoleted. This one probably will be.

thanks,
Rob

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 8 Oct 2020 08:51:07 -0400

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

tim

---

From: Warren Kumari <[email-masked]>
Date: Thu, 8 Oct 2020 08:58:09 -0400

> 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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 8 Oct 2020 13:01:14 +0000

Thank you all for the review (catching a good point) and even more for the quick resolution

-éric

-----Original Message-----
From: iesg <[email-masked]> on behalf of Warren Kumari <[email-masked]>
Date: Thursday, 8 October 2020 at 14:59
To: Tim Wicinski <[email-masked]>
Cc: The IESG <[email-masked]>, Brian Haberman <[email-masked]>, "[email-masked]" <[email-masked]>, DNS Privacy Working Group <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dns-privacy] Warren Kumari's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)

    Thanks again,
    W