After a little bit of online discussion with the chairs-to-be and the AD, I’m following my earlier email up with a couple of small suggested edits to the charter. EXISTING: Milestones: Dec 2014 - WG LC on an problem statement document Mar 2015 - WG selects one or more primary protocol directions Jul 2015 - WG LC on primary protocol directions
SUGGESTED: Milestones: Dec 2014 - WG LC on an problem statement document Mar 2015 - WG selects primary protocol directions May 2015 - WG LC on privacy evaluation document Jul 2015 - WG LC on primary protocol directions The suggested privacy evaluation draft would describe methods for assessing the results of the DNS private exchange mechanisms. Is the application of one or several mechanisms an effective choice for mitigating against pervasive monitoring in particular operational configurations or use cases? I argue that this is important to help with the two cases I posed in my first message, where a channel encryption mechanism could be applied between End-system and Iterator but not mitigate at all. Additional suggested wording about privacy evaluation for the charter body, addition of one sentence: EXISTING: The primary focus of this Working Group is to develop mechanisms that provide confidentiality between DNS Clients and Iterative Resolvers, but it may also later consider mechanisms that provide confidentiality between Iterative Resolvers and Authoritative Servers, or provide end-to-end confidentiality of DNS transactions. Some of the results of this working group may be experimental. SUGGESTED: [Add to the end of the above paragraph] The Working Group will also develop a privacy evaluation document to provide methods for assessing how well the goal of mitigating against pervasive monitor is met, and to provide example assessments for common use cases. Best, Allison On Oct 6, 2014, at 12:52 PM, Mankin, Allison <[email protected]<mailto:[email protected]>> wrote: A comment of Olafur's has triggered me to write something I like about the charter, and also something in support of Stephane. Olafur wrote; So I think the charter is right in saying “will focus on last mile” and check if that solution will scale to other cases. The charter uses the noun “mechanisms” not “solutions, and doesn't to indicate the development of single one-size-fits all solution, as I read it. It also makes explicit in the milestones that multiple “solutions” might be developed. Stephane’s existing draft about the problem statement has done a great job in leading us to understand that there are varied operational realizations that need to be served by IETF’s work here. Operationally end-systems reach the iterative resolver and beyond in different ways. Taking just two, there’s the case in which a stub and iterative resolver are both running on the same computer, and the case in which many end-systems reach the iterative resolver through enterprise name system management of some kind. In both cases, you can see that the end-systems are subject to having their queries linkable (in a privacy-revelation sense) and subject to compromise of their DNS private exchange, even if some mechanism for confidentiality of the stub-to-iterator is present. I’d like to see the working group propose and specify whatever the needed deployable mechanisms are to provide the end-system(s) with DNS private exchange, and not start with a mechanistic boundary. Best regards, Allison On Oct 6, 2014, at 11:26 AM, Olafur Gudmundsson <[email protected]<mailto:[email protected]>> wrote: On Oct 6, 2014, at 8:44 AM, Stephane Bortzmeyer <[email protected]<mailto:[email protected]>> wrote: [Keep [email protected]<mailto:[email protected]> in the loop only if it is substantive comments on the WG creation, please] On Fri, Oct 03, 2014 at 10:38:35AM -0700, The IESG <[email protected]<mailto:[email protected]>> wrote a message of 68 lines which said: The primary focus of this Working Group is to develop mechanisms that provide confidentiality between DNS Clients and Iterative Resolvers, I do not see why the group is limited to this point. 1) Some technques (such as hop-to-hop encryption) work exactly the same for this case and the case of resolvers<->authoritative. 2) The problem of data gathering by authoritative name servers is as serious as the problem of sniffing by third parties between a stub client and a resolver, and should be addressed at the same level. Well different techniques might be “better” in the two cases, i.e. connection from client to Recursive resolver may only be kept open for a short time while the connection from Recursive Resolver to a BIG DNS data provider might be always-on. So I think the charter is right in saying “will focus on last mile” and check if that solution will scale to other cases. Olafur
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
