[DNSOP] DNS Privacy Use Cases, Requirements and Constraints.

[Phillip Hallam-Baker <[e-mail]>]

I think we need some use cases to ground discussion. These are the use
cases I have been considering:


A) Alice, surfing the Web from her own machine at home does not want her
Web browsing history to be revealed to other parties.

A1) Note here that Alice might also use the same machine to access her
employer's Intranet under a BYOD program.


B) Bob, accessing the Internet from a machine provided by his employer. His
employer does not want the existence of machines within the corporate
enterprise under a 'split DNS' configuration to be revealed to other
parties.

B1) Note here that Bob might also use the same machine for personal use and
not want his employer to know that he is using it to surf the Web.
Depending on the circumstances, this may or may not be acceptable. If the
machine is in the control system of a nuclear power station then his
employer may reasonably wish to prevent him using it to view 'bigboobies.com'.
The issue here then is notice. A 'captive configuration' may be acceptable
but not if it is imposed covertly.

C) Carol's Coffee pot, an embedded device accesses the Internet to download
current prices and order supplies.

The point of this use case is that the coffee pot does not have an
affordance for a user interface suitable for configuring trust interfaces.
Ergo the device is going to be operating under control of a DNSSEC trust
policy that is specified externally, whether this is in the form of a
static policy description file downloaded into the device periodically or
imposed externally at the resolver.


Within these use cases we have a number of trusted actors and different
privacy concerns with respect to each. Note here that 'trusted' does not
mean 'trustworthy'.

Resolvers:

Any resolver can observe and correlate DNS request traffic, in particular
tracking users by the IP addresses that they present. While countermeasures
may reduce the extent to which this is possible, eliminating this is very
difficult.

1) Promiscuous Resolver

If we are to improve DNS security at all, the lowest handing fruit is to
kill the crazy idea of taking DNS service from the nearest server.
Regardless of whether DNSSEC is fully deployed and every domain is signed
or not, this is a shoot-yourself-in-the-foot configuration.

A resolver can always mount a denial of service attack on the client and
the best a client can do is to determine that either it is under attack or
someone has blundered in their DNSSEC configuration.

This configuration, though the default case today does not satisfy any of
the use cases and is therefore strongly deprecated.

1a) Captive resolver

Even more annoying is the resolver that substitutes itself for the
preferred resolver chosen by the user. This is commonly used in WiFi
portals to establish network connections. Although the specific solution to
this use case is out of scope, any DNS privacy implementation is going to
have to cope with the imposition of captivv resolvers as a constraint.

2) Selected Resolver

An improvement on the selected resolver is the case that the resolver
service is chosen by the user or administrator of the machine.

In the case that a zone does not deploy DNSSEC (currently the vast
majority) such a resolver is trusted not to perform an integrity attack.

In the case that a zone has DNSSEC deployed, deployment may follow either
of the patterns established in XKMS and later SCVP. Such a resolver will
always perform path discovery (i.e. resolution) and validate the path
discovered. But the client may or may not re-validate the discovered path
to verify that it chains to a root of trust.

There are security arguments to be made for both deployments in different
use cases. For example, the Coffee pot (use case C) is probably better
served by a validating resolver controlled by Carol rather than performing
complex path validation in the embedded device.

2a) Selected Resolver (Discovery)

A discovery only resolver is less trusted than a validating resolver.

2b) Selected Resolver (Validating)

Since a validating resolver is absolutely trusted by the client, such a
resolver is only acceptable when it is trustworthy. This would typically
mean that the resolver is operated by the relying party directly. For
example a resolver operated by an enterprise for the enterprise network. In
the home, a validating resolver might be operated by the homeowner as part
of their 'home automation' infrastructure.


3) Authoritative server

The Authoritative server is the ultimate source of a DNS assertion. When
considering the privacy implications of such services, there are two
important subclasses:

3a) Public aggregated service

Many DNS commercial providers support a large number of domains, from
thousands to hundreds of millions.

3b) Corporate service

Other DNS servers support only one enterprise with a small number of
related domains.


Privacy of authoritative service queries and responses.

One of the main challenges in designing an efficient mechanism to protect
privacy of queries made to authoritative servers is that the number of
servers is very large and it is arguably impractical for a resolver to
establish a security session with every server it contacts.

This objection may be moot however if traffic analysis attacks are
considered. Traffic analysis reveals very little about the requestor
contacting a public aggregated service because there is a large forrest of
queries amongst which privacy sensitive queries can hide. But queries
directed to a corporate service reveal much more. At the limit, traffic
analysis of a query directed to a service that only supports one domain
discloses as much as content disclosure.

If we limit the requirement to encrypt queries to public aggregated
servers, the key management problem becomes quite tractable. While there
are millions of authoritative servers, the number of large scale public
servers is in the hundreds or thousands.


Constraints

1) Latency

Browser vendors are adamant that they will not accept any increase in DNS
response latency

2) Denial of Service

Performing public key operations imposes a significant processing load on a
server. An attacker could easily perform a DoS attack on a resolver or
server by directing a stream of requests to initiate a key exchange.

3) Captive portal

A client must be capable of functioning when behind a captive portal even
if the DNS service imposed by the captive portal is only used to establish
a network connection and will be ignored subsequently.

-- 
Website: http://hallambaker.com/