On Tue, Oct 21, 2014 at 3:36 AM, Jay Daley <[email protected]> wrote: > > 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. > > Um, RFC 4501 created one; other than the existing erratum noting a typo in the reference to RFC 3490, is there something wrong with it?
regards, Ted > 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 > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
