[DNSOP] An approach to DNS privacy

Phillip Hallam-Baker <hallam@gmail.com> Sat, 08 March 2014 20:57 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BE41A02BE for <dnsop@ietfa.amsl.com>; Sat, 8 Mar 2014 12:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwkfIBe-au5Y for <dnsop@ietfa.amsl.com>; Sat, 8 Mar 2014 12:57:30 -0800 (PST)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D26701A01F8 for <dnsop@ietf.org>; Sat, 8 Mar 2014 12:57:29 -0800 (PST)
Received: by mail-lb0-f173.google.com with SMTP id p9so3656599lbv.4 for <dnsop@ietf.org>; Sat, 08 Mar 2014 12:57:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=olQKXmzUDFoNZJ4EqTMxlb8oThf6Ju7qIoOSA6VsfF4=; b=MY+gcNK1BORs+UUVZsg8WmfQ1KmNlbMBo16r3VZ66PuKZoBdD6TyN7mUz17HDeyXr/ QsLDb39QdtlLg52Em380fr97tFc9NHmuuubx0I9LgWD7ZPlSS09C2hXSMV3+ULgH8KMN NKIK9YjzLP5Yupg88pJ1um4D6hiNFKxjaRqHqyRVQ+mszjrvYN3OS6JhTSeeGkYRGl4D tunh5zBZDh3gF9uRqVaYNenLyxzu/qKa+4Ost2pE5N5MDHOPHCfEWvsUVl1jyN6IZDGX GCc6EUPy8/3ikF5EICC1VHWuVClsd2bjNRu0cn/jmIN9ICTmbKjZPyqtMF7m/i5vBwDK YKig==
MIME-Version: 1.0
X-Received: by 10.152.115.178 with SMTP id jp18mr11869447lab.23.1394312244348; Sat, 08 Mar 2014 12:57:24 -0800 (PST)
Received: by 10.112.37.168 with HTTP; Sat, 8 Mar 2014 12:57:24 -0800 (PST)
Date: Sat, 8 Mar 2014 15:57:24 -0500
Message-ID: <CAMm+LwgZOPvGX_mzqmpt1zDj3cZdF0y2du=Di5q8Vfo4aYjNYw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c3474c07cd5a04f41e9e47
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/CyKwH6mjc6LM2iet9z4uBdswazY
Subject: [DNSOP] An approach to DNS privacy
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Mar 2014 20:57:33 -0000

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/