i am not a member of the dns-privacy@ mailing list, but i was cc'd here, so i'm responding. i hope that someone will kindly forward this response to that mailing list, because i think my direct reply will bounce (as it should, due to the spam problem.)
first let me say that i think privacy in dns is a very sensitive topic. there are three points in the dns communication mesh where surveillance is possible: 1. stub to recursive 2. recursive to authoritative 3. zone maintainance i am in favour of query minimization on #2 because the current system exposes unnecessary information to third parties. bortzmeyer's draft is a great start on that. beyond query minimization i see no benefit or need for secrecy since dns is a publication system -- if you don't want people to see your information, don't put it into the dns. cache miss transactions (#2 above) expose only server IP addresses, not end-user IP addresses, and no re-use events. as such it has always been my position that there is no PII and no privacy impact from having these recorded and analyzed. i would not like to see the IETF work in that area. i have a similar position on #3 -- if a zone administrator wants their data to be secret, don't publish it, don't put it into the DNS at all. i know that most people restrict zone transfers to a small set of known secondary servers, or to the holders of a small number of TSIG keys, but i have always viewed this as a way to protect the servers, not as a way to keep data secret. the data is in the DNS -- so it is by definition not intended to be secret. the longer topic is #1, stub-to-recursive traffic. i think this is PII, and i oppose surveillance of it, and i oppose collection and analysis of it by anyone not a direct party to the relationship between the stub operator (so, the owner of a laptop or smart phone or whatever) and the recursive operator (who might be the employer or the ISP of the stub operator, or google dns, opendns, or similar). this data path should in my opinion be protected against third party observation, either by VPN or IPSEC, or by a new stub-to-recursive transport. it is that third option that should concern us -- i would like to see an XML schema for DNS data (similar to bortzmeyer's effort) and a URL schema for encoding DNS queries, and we should move the stub-to-recursive data path to HTTPS. if XML loses this war that i'll suggest a RESTful/JSON API. ultimately we should connect to an HTTP listener and use a URL pattern like /dns/query/QNAME/QCLASS/QTYPE and get back an XML or a JSON blob. TLS, with PFS, should protect the privacy of this data. in that sense i would be alarmed to hear a proposal that the DNS protocol itself should add features to support secrecy or privacy, because that problem can be solved in the transport, and because we need an HTTPS "Web API" to fix many other emergent and compelling problems in the stub-to-recursive layer. so, i don't understand why the IESG approved this working group, unless it's to rubber stamp what we already know, or to investigate things we already know should not be done. with that background, let me respond to hugo's note, on which he helpfully cc'd me. > Hugo Maxwell Connery <mailto:[email protected]> > Monday, October 20, 2014 10:51 AM > Hi, > > I am deeply supportive of the IETF's effort to address > user privacy in all contexts. Pervasive monitoring > is an attack, and I am grateful for the IETF acknowledging > it as such. > > The core mission of DPRIVE is stated as "confidentiality > between DNS Clients and Iterative Resolvers" with possible > extension to end-to-end type scenarios. Clarifying as > "DPRIVE will address risks to end-users' privacy". i do not accept that redefinition as a "clarification". > > I believe that an extended discussion of the area of > consideration is worthwhile. > > The landscape could be classified into: > > A) An end-user running some application that needs DNS, and > it (we hope) uses the stub resolver associated with the > operating system. I group these as A. > > B) A calls some iterative resolver, B, which returns > from cache or calls a collection of authoritative > resolvers, C. > > C) The collection of authoritative resolvers. > > These can be all on different systems (normal) or even > all collocated ($ dig localhost). > > One can insert encrypted networks between components, and > those networks can handle all or some fraction of a client's > traffic. > > As there is currently no provision for encrypting DNS > traffic, all claims that it is solved, for 'A to B' or > anywhere, by VPN or TOR (for example) are all false. i disagree. a client could have a policy that only an encrypted tunnel or negotiated IPSEC is acceptable, and return SERVFAIL if such is not available. some sensitive networks already work this way, so, i have witnessed and consulted on existence proofs of the statement you group into the set "are all false". > > What they do is move the traffic to another end-point and > provide anonymity in proportion to the volume of the community > using the end-point. TOR is far superior to a VPN as its > endpoint cannot know the source, by design. you're overstating the problem and then claiming there is no solution. that's a straw man fallacy. > > Providing a standard for encrypting 'A to B' would create > a very similar situtation, where the privacy would really > be based on anonymity. Only one person using the resolver? > Then all the authoritative queries are generated by their > queries. This would still be an improvement as the frequency > of their queries would be unknown (i.e the TTL controls > the volume of frequency information leakage per zone). > > So, it would seem to me that DPRIVE should also consider > the 'B to C' phase. I state this, because TOR already > provides what only 'A to B' encryption could: anonymity > based on the volume of users. i agree that if an attacker has control over the stub's choice of recursive server, such that they can assign the surveillance target a particular recursive server, then "stub-to-authoritative in the clear" would be an information leak. however, that overstates the starting conditions. the stub's recursive is either manually configured, or it is assigned by their DHCP server operator, and either the owner themselves or the DHCP server operator have many other methods of collecting this traffic. so your starting conditions are operatively equal to the null set. === in conclusion, let me strongly urge that DPRIVE consider point solutions such as query minimization and an HTTPS based transport between stubs and recursives, and avoid system level structural changes to DNS itself. let the DNSSEC effort, now in its 18th year, be a cautionary tale. -- Paul Vixie
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
