[dns-privacy] Private-DNS drafts

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

All,

I have uploaded a new version of

* A General requirements draft for DNS privacy and related security concerns

* Private-DNS, a specification that meets the requirements set out above

* SXS-Connect, a connection management protocol that is used by
Private-DNS but has much wider application.

As always, the examples in the text are generated from the current
code which I will push to Sourceforge sometime soon.

http://tools.ietf.org/html/draft-hallambaker-dnse-01
http://tools.ietf.org/html/draft-hallambaker-privatedns-00
http://tools.ietf.org/html/draft-hallambaker-wsconnect-07

The actual Private DNS proposal is very short. The draft is currently
15 pages including boilerplate and that includes several pages of
wireline example data.

Layering the query protocol directly onto UDP or HTTP is a lot simpler
than trying to use DTLS. I can go into detail as to why DTLS does not
help but the basic problem is that DTLS is built on TLS and TLS
expects to run on top of DNS. It is really not possible to get either
to work underneath DNS without a lot of hassle. And since the idea of
building on an existing protocol is to make life easier, why on earth
bother?

Working from scratch results in a very clean protocol that can be
implemented very simply.

The query protocol uses a ticket+secret key approach as introduced in
Kerberos. In fact you can use Kerberos keys if you like. As far as the
client is concerned the ticket is just an opaque blob of up to 255
characters.

This approach allows a stateless resolver or authoritative to produce
a response without the need to perform any out-of-band lookups.

One decision that might be controversial is that every message has
authentication. This is essentially free from a cryptography point of
view, it only adds 17 bytes to each message. The payoff is that it
allows two problems with DNS protocol to be completely eliminated:

* DDoS amplification attacks
* Response spoofing attacks

A service that receives a request that does not authenticate simply
rejects it. Requests and responses are bound cryptographically so as
to prevent response substitution attacks.

One feature I put in the spec but not in the code so far is protection
against traffic analysis by adding padding to each packet. This is
cheap and effective.


The problem that the query protocol does not attempt to solve is the
problem of how to setup the ticket+secret. To do this we use the
sxs-connect Web Service which in turn layers on TLS.

Unlike the query protocol, this particular application does not raise
layering issues. The idea is that when you set up the platform to
perform Private DNS you start off by giving it the DNS name of the
Private-DNS key exchange service. This would be a one time setup that
is typically layered on legacy DNS.

For a constrained device the story is a little more complicated.
Basically we can do the key setup on another machine. This means that
we can do Private-DNS on really low end platforms like Ardulinos where
adding a TLS stack eats up a huge amount of the device memory.


Current Limits:

The key exchange setup is currently exchanging the key en-clair which
is not what I want to do in the final system. The issue is that I want
the application programmer to be able to limit reliance on TLS to
authenticate the key exchange. So instead of having to audit the whole
of OpenSSL and the whole of the JSON parser stack to check that there
are no copies of the private key, it would only be necessary to look
at the code that did the Diffie-Hellman exchange.


Future:

Almost all the complexity in the system is in the key setup. While the
system does allow for a fairly simple key setup without
authentication, the spec also supports a more robust exchange. There
are three additional projects that leverage the same exchange:

* OmniDiscover
* OmniPublish
* Simple Confirmation Service

OmniDiscover is the Omnibroker service I started with. It is a much
higher level service and allows discovery of client endpoints as well
as hosts. So in Jabber you want to connect to [e-mail], well
OmniDiscover supports that type of query.

OmniPublish is the publishing counterpart. When a service starts up it
wants to do a number of things. It wants to acquire cryptographic
credentials for its SSL service, publish itself in the DNS, poke holes
in firewalls. Providing a simple one stop shop for these features
makes writing code a lot easier.

Simple Confirmation Service is basically a replacement for One Time
Code tokens like SecureID. We have these smartphones. Why not use them
in a smart way?



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