On Mon, Nov 3, 2014 at 10:34 AM, Paul Hoffman <[email protected]> wrote: > On Nov 2, 2014, at 12:57 PM, Stephane Bortzmeyer <[email protected]> wrote: >> >> A reviewer told me privately that it is not clear, from >> draft-ietf-dprive-problem-statement-00.txt, what are the actual >> considerations/issues/problems. They are mentioned but not highlighted >> enough, he said. > > I did not have the problem that that reviewer did, but WGs in the past have > had problems with "the problem statement document indicates X" vs. "it > doesn't say that". > >> He suggested to add prominent CONSIDERATIONS from time to time, for >> instance when discussing source IP addresses, having: >> >> CONSIDERATION NNN: "exposing source IP addresses of DNS queries raises >> privacy risks" >> >> Advice? > > My preference is not to have three categories, but just one: problems. > Problems are issues, and problems have considerations, but what the WG needs > is a list of problems that it needs to try to solve.
My preference is to do a proper use case based analysis in which we start off with a set of use cases motivating the design and derive requirements and constraints from those use cases. The problem with problems is that they lack context. Building a protocol that resists pervasive warrantless surveillance is completely different to the problem of building a protocol that supports covert action by dissidents in a police state. I want to be able to track back each requirement to the use cases that motivate it. Another concern I have that I raised on DNSOPs is that our problem is securing the DNS as it is used in the real world, not securing the DNS protocol described in the standard. There are many real world controls that are necessary to prevent abuse of resolvers and authoritative servers that rely on information being visible. We don't necessarily need to ensure that those particular controls can be used with the encrypted protocol. But we do have to provide a substitute that is at least as effective. My starting point two years ago was to provide a proper solution to the issues raised by TCP fallback and port 53 middleboxing and amplification attacks by authenticating the client-resolver link. The encryption was a nice to have byproduct. For confidentiality, my goal is limited at this stage to establishing some accountability. I don't think we can design and deploy a DNS privacy protocol that resists lawful intercept demands within 18 months but in that time we can certainly develop and begin to deploy an infrastructure that blocks unlawful intercept without collusion by the trusted party (in this case the operator of the resolver). Forcing the opposition to move from a warrantless attack to getting a warrant imposes significant costs. Military lawyers are not used to telling a General he cannot do what he wants but Federal judges certainly don't mind. Phill _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
