Subject: [dns-privacy] [dprive-problem-statement] Clearly marking privacy considerations?

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 2 Nov 2014 21:57:40 +0100

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.

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? 

We may discuss it here and/or during the dprive-problem-statement slot
in Honolulu (unless there is a conflict with the scuba WG).

---

From: Christian Huitema <[email-masked]>
Date: Sun, 02 Nov 2014 13:32:22 -0800

> CONSIDERATION NNN: "exposing source IP addresses of DNS queries raises

Passive monitoring records the domain names queried by IP addresses. 
This can be us to identify the user behind the address -- finding 
quickly the domain names of private mail server, business mail server, 
preferred services, etc. Some of that information can be also retrieved 
from traffic analysis, but all.

Passive monitoring divulges access to named services, which is more info 
than mere IP addresses when the services use shared infrastructure like 
CDN or server pools.

Real time passive monitoring enables "automated spoofed response," which 
are used to instantiate MITM attacks.

-- Christian Huitema

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 3 Nov 2014 11:05:20 +0100

On Sun, Nov 02, 2014 at 01:32:22PM -0800,
 Christian Huitema <[email-masked]> wrote 
 a message of 33 lines which said:

> Passive monitoring records the domain names queried by IP addresses. This
> can be us to identify the user behind the address 

It was just an example. My question was not for a discussion on _this_
specific consideration but about the meta-idea of indicating privacy
considerations more clearly.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Nov 2014 07:34:00 -0800

> considerations/issues/problems. They are mentioned but not highlighted

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".

> CONSIDERATION NNN: "exposing source IP addresses of DNS queries raises

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.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Nov 2014 14:36:33 -0500

> 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 sol…

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