On 21/10/2014, at 2:10 pm, Paul Vixie <[email protected]> wrote: > 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)
Done: http://tools.ietf.org/html/draft-daley-dnsxml-00 > and a URL schema for encoding DNS queries, What an interesting idea. > 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. I prefer /query/QNAME.json?qtype=QTYPE /query/QNAME.json?qtype=QTYPE&qclass=QCLASS /query/QNAME.xml But I suspect that needs a lot more thought. Jay > 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 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 -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
