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 <[email protected]> wrote: > On Wed, Oct 7, 2020 at 5:16 PM Peter Koch <[email protected]> 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 >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
