Subject: [DNSOP] An approach to DNS privacy

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Mar 2014 15:57:24 -0500

In my view we need to consider different privacy issues in the
stub-resolver and resolver-authoritative interactions.

In the stub-resolver interaction the primary objective is to encrypt
requests and responses without impacting latency.

For a heavily trafficked resolver, the resolver-authoritative interaction
can be addressed with caching and by pre-fetching the bulk of the requests.
But this approach does not work so well for the lightly trafficked resolver
and especially not a local resolver deployed in a home network.

As a result, while I am focusing on the stub-resolver interaction, the
resolver-authoritative interaction also needs to be considered in a
solution. It might well be that the same approach would be applicable to
secure the resolver-authoritative interaction but I have not considered
that in depth at this point.

Any approach using encryption needs to consider three parts

1) Discovery that the option is supported by the server to support
opportunistic upgrade.

2) Distribution of a shared symmetric key

3) Formatting encrypted requests and replies.

The first and the last are straightforward:

A server that supports the option simply advertises it as an EDNS code. If
additional information is required this can be supplied in new resource
records.

Alternatively, given that configuring DNS servers is a highly
unsatisfactory process today, we might well want to use legacy DNS as a
mechanism for bootstrapping the selection of a trustworthy DNS resolution
service.

So Alice might configure her home systems by selecting the 'example.com'
DNS service provider on her browser, or alternatively in a DNS proxy built
into her home network gateway device.

The last part, formatting is pretty simple as well. We have a shared
symmetric key between the client and server. Since we don't want to expose
the key on the wire we must tell the server which key to use by means of a
key identifier in the request. We also need to provide some mechanism to
allow the client to work out which key to apply to responses.

The shared secret must not be shared widely to avoid disclosure, this
typically means that it should be unique to one client/server instance.

We expect that most services would choose to avoid the need to maintain a
database of id/key mappings by using the 'encrypt the key in an opaque
identifier' trick used in Kerberos and widely employed in cookie type
schemes. We do not and should not attempt to standardize the format of the
identifier however as only the server side of the communication needs to
agree on the format.

Since we have a shared secret, we can and should add an authentication
check so that the request can be matched to the response and prevent
response spoofing attacks. The cost is negligible and provides protection
even when DNSSEC is available. In particular consider attacks where a MITM
is modifying DNSSEC signatures inside the encrypted packets. Without an
independent integrity check on the response, a client has no way to
distinguish this from an untrustworthy resolver.

Given the number of bits required, the simplest approach would be to create
a new QCode for an 'encrypted query' and encode the request in the request
label.

Note that since both the client and the server have to be aware of the new
protocol we can make more radical changes if desired. For example, using
the multiple requests feature supported in the protocol but currently
unusable as clients don't support it.

The complicated part of the protocol then is how we establish the shared
secret. We do have some important constraints though.

The first is latency, we can't afford public key operations on every
request. Even if we could use exotic public key crypto to reduce latency to
acceptable bounds we will be exposed to a Denial of Service vulnerability
as even the cheapest public key crypto scheme is more CPU intensive than
sending a UDP request.

This means that we need to do the key exchange out of band with respect to
the DNS query. Which fits perfectly with a selected resolver application or
a highly trafficked authoritative server.

The second constraint is Denial of Service vulnerability. A server cannot
afford to perform a public key operation without some level of proof that
the source IP address is legitimate. Which means looking at an IP round
trip first.

A third concern is whether we care about the resolver building a profile of
the user across requests. This is a very hard problem which requires us to
perform a separate public key agreement operation each time we wish to
'insulate' one set of behavior from another.

For example, a resolver might choose to encode the identity of the user in
the private keys it assigns. Making the behavior of the resolver robustly
unlinkable is very hard. It may also be futile if the only viable business
model for offering public resolution services turns out to be advertising
based.

Once established, a shared secret is in principle no less secure than
public key for authentication/encryption. The volumes of data to be
encrypted are insignificant compared to a 128 bit key space. So we can and
should consider the key setup to be a once-and-forget operation rather than
something to repeat every day or hour. Worst case we have to repeat our
setup occasionally when administration of the service fails badly and we
have to recover.

These considerations make me look towards TLS rather than DTLS as a
security layer.

In WS-Connect, I rely on TLS to secure the key exchange. This si a JSON
based HTTP/REST web service that has already been implemented for a very
similar protocol:

https://datatracker.ietf.org/doc/draft-hallambaker-wsconnect/

Relying on TLS is not best practice, I would prefer to do a secondary key
exchange so that we are assured of security even if the TLS gets messed up.
But remember that this is a one time fire and forget type operation.

Using WS-Connect we establish a shared secret relationship with multiple
hosts within a given service. There is also the option of the service
telling the client that different protocols and/or transports are
supported. In effect WS-Connect supports a Web Service level version of the
SRV record and hands the client a kerberos-like ticket for each one.

We could of course use GSSAPI for the same effect, but since these are
inherently two party exchanges we don't need to standardize the ticket
format.

Depending on the specific use case we may or may not want to authenticate
the client to the service.

* If we are attempting to conceal the end-user's behavior from the resolver
we obviously don't want to authenticate the end user!

* If we are providing access to a split horizon DNS and don't want to have
the extra chronic unreliability of every VPN it has been my immense
displeasure to have inflicted on me, then of course we want to authenticate
the client strongly and quite likely want to re-authenticate on a regular
schedule.

* If we are dealing with an embedded device like the coffee pot then we
probably want to do a one time authentication to bind the device into the
network.

* If we are dealing with a paid service then we want to authenticate.

WS-Connect already supports both the unauthenticated and authenticated
client configurations.

Preventing request linkage.

Encrypting requests and responses prevents an attacker accessing the
contents of the message but may leak information about the identity of the
user to an observer.

For example, Alice uses her laptop at two hotels, unless countermeasures
are taken this could allow the hotels to link her two sessions.

One solution to this is to issue a 'book' of access tickets rather than a
single ticket. On making the initial connection, Alice is issues a book of
5 tickets. Each time her network connection context changes, her client
automatically uses a different ticket. Each request contains a new ticket
and encrypted private key to allow her to keep her book topped up.

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

---

From: Florian Weimer <[email-masked]>
Date: Sun, 09 Mar 2014 11:28:18 +0100

* Phillip Hallam-Baker:

> For a heavily trafficked resolver, the resolver-authoritative
> interaction can be addressed with caching and by pre-fetching the
> bulk of the requests.  But this approach does not work so well for
> the lightly trafficked resolver and especially not a local resolver
> deployed in a home network.

Does encryption really make a difference there?  In most
jurisdictions, home networks use recursive resolvers whose operators
are required by law to provide cleartext copies to local authorities.
Encryption won't change that.

If it is about securing broadcast media, just run IPsec between the
CPE and the first ISP router with trusted ARP and routing tables.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 9 Mar 2014 09:27:09 -0400

> Encryption won't change that.

The protocol is premised on the user or administrator choosing their own
resolver.

If the resolver service is provisioned by a jurisdiction outside the scope
of the legal requirements that you claim, it is null and void.

But first, cite actual legal authority because I don't believe your
interpretation of the law is remotely correct.

---

From: Florian Weimer <[email-masked]>
Date: Sun, 09 Mar 2014 15:26:31 +0100

> interpretation of the law is remotely correct.

§ 8 Abs. 3 TKÜV:

| Wenn der Verpflichtete die ihm zur Übermittlung anvertraute
| Telekommunikation netzseitig durch technische Maßnahmen gegen
| unbefugte Kenntnisnahme schützt, hat er die von ihm für diese
| Telekommunikation angewendeten Schutzvorkehrungen bei der an dem
| Übergabepunkt bereitzustellenden Überwachungskopie aufzuheben. […]

| If the obligated party [the organization to which these rules apply]
| uses technical measures at the network layer to protect submitted
| communications against unauthorized disclosure, it shall revert the
| protections on these communications for the surveillance copy
| provided at the handover interface.

U.S. law is similar (47 U.S. Code § 1002 (b) (3), if that citation is
correct):

| A telecommunications carrier shall not be responsible for
| decrypting, or ensuring the government’s ability to decrypt, any
| communication encrypted by a subscriber or customer, unless the
| encryption was provided by the carrier and the carrier possesses the
| information necessary to decrypt the communication.

If your ordinary resolver operator is a "carrier" is somewhat
questionable, but resolver operators generally comply with requests
for cleartext copies of traffic transitioning through their networks.

I have no doubts that these operators will ask implementors to add the
necessary features to keep these capabilities—or they will just turn
on indiscriminate query logging.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 9 Mar 2014 10:54:34 -0400

On Sun, Mar 9, 2014 at 10:26 AM, Florian Weimer <[email-masked]> wrote:

> | Übergabepunkt bereitzustellenden Überwachungskopie aufzuheben. [...]
>
> | decrypting, or ensuring the government's ability to decrypt, any
> necessary features to keep these capabilities--or they will just turn

We are not a carrier or an obligated party.

The model where the carrier provides DNS resolution is bogus and obsolete
for the reasons you cite.

People are tired of being spied on without due process. Lets see some of
the Abu Ghraib torturers facing criminal trial.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Mar 2014 16:26:51 +0100

On Sun, Mar 09, 2014 at 11:28:18AM +0100,
 Florian Weimer <[email-masked]> wrote 
 a message of 20 lines which said:

> In most jurisdictions, home networks use recursive resolvers whose
> operators are required by law to provide cleartext copies to local
> authorities.

This (and other similar privacy-invasive cases) is precisely why we
need to improve DNS privacy.

> Encryption won't change that.

As mentioned in draft-bortzmeyer-dnsop-privacy-sol, encryption is
_one_ solution, it is not _the_ solution. At least two other
techniques can complement encryption, QNAME minimization and a caching
resolver on your own machine (possibly forwarding to the IAP's
resolvers).

> CPE and the first ISP router with trusted ARP and routing tables.

If it were so simple ("just run"), why isn't it pervasive?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 11 Mar 2014 11:39:17 -0400

> If it were so simple ("just run"), why isn't it pervasive?

The point is not to merely encrypt, the point is to allow control over the
encryption. That is:

* The client knows that the request/response SHALL be encrypted

* The client and server both know that they are the only parties that could
disclose the key

---

From: Florian Weimer <[email-masked]>
Date: Sun, 16 Mar 2014 16:04:09 +0100

> We are not a carrier or an obligated party.

We aren't, but the people who run our protocols and code mostly are.
If they aren't, they comply with most requests directed at them just
to avoid being declared a carrier or an obligated party explicitly.

> The model where the carrier provides DNS resolution is bogus and
> obsolete for the reasons you cite.

I think we are being to see a move in a different direction, where end
users are no longer in a position to run resolvers.  For me, that's
not just theoretical because I've been forced to switch hosting
providers because my current one filters DNS traffic to certain
ISC.ORG name servers, apparently in an ill-advised attempt at prevent
their customers from taking part in amplification attacks.

> the Abu Ghraib torturers facing criminal trial.

And more encryption helps with that how?

Abu Ghraib would have been just another prison with an abuse problem
without the pictures leaking out.  Proper cryptography with extensive
key management could have prevented that.  It is difficult to predict
how technology will be used.  A decade or two ago, many of us thought
that encryption and the ubiquity of software vulnerabilities (or the
fallibility of information systems in general) would help to keep
powerful governments in check.

When I first sketched the technology that is now cited in quite a few
DNS privacy discussions, I thought I was doing something genuinely
helpful.  Now the picture is less clear.