Apologies for the top-post and the length of quoted text, but I wanted to retain some context of Vixie's remarks.
I would also like to express my concern on the similar issues that Vix expressed here, but perhaps a dprive "implementation and architecture" document would be a good idea? I am afraid that this efforts gets too far down the path before realizing how some implementation of the "privacy path" before realizing that the scheme breaks things like passive DNS collection. For security operations folks, pDNS data collection is an imperative in how we do reputation, etc., especially consider where the encryption path is implemented: > > 1. stub to recursive > 2. recursive to authoritative > 3. zone maintainance > I apologize if this topic has already been brought up, and if it has, perhaps some kind soul could point me to the proper index in the list archive. :-) Cheers, - ferg On 10/20/2014 6:10 PM, Paul Vixie wrote: > 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 > -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
