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

[Tim Wicinski <[e-mail]>]

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


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

> On Wed, Oct 7, 2020 at 5:16 PM Peter Koch <[e-mail]> 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
>