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

[Tim Wicinski <[e-mail]>]

Warren


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

> On Wed, Oct 7, 2020 at 3:29 PM Brian Haberman <[e-mail]>
> 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).
>

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.



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