On 23/10/2014, at 8:55 am, Ted Hardie <[email protected]> wrote: > 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?
Thanks Ted, I had no idea that RFC existed. The only problem I can see with it is that it doesn't go far enough, but what it does it does simply enough. Jay > > 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 > > -- 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
