Subject: [dns-privacy] Private-DNS drafts

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 9 May 2014 17:38:46 -0400

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 [email-masked], 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/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 May 2014 15:40:23 +0200

On Fri, May 09, 2014 at 05:38:46PM -0400,
 Phillip Hallam-Baker <[email-masked]> wrote 
 a message of 120 lines which said:

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

In this message, I'll talk only about this one,
draft-hallambaker-dnse-01.
 
Good idea to try to have a "requirments" document between the "privacy
considerations" document and the various "solution"
documents. However, I find that the requirments expressed in
draft-hallambaker-dnse are too general: for instance, "[R-C-ACTIVE]
Prevent or mitigate disclosure of request and response data against an
active attacker on every contact" is nice but seems very difficult to
achieve, and the draft does not mention the costs or the tradoffs
(except the last sentence of "security considerations").

Also, I find that a requirment is missing: "limiting, to the maximum
extent possible, the amount of data sent to forwarders or
authoritative name servers". The draft only mentions the risk of
profiling (so I assume a solution allowing anonymous clients would
address it). But the qnames themselves are information and sometimes
personal information and we want to limit every leak.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 May 2014 14:49:47 +0100

> draft-hallambaker-dnse-01.

Yeah, I like that draft. Still haven't had a chance to read
the others, but that one looks good, as do Stephane's
comments on it.

S.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 May 2014 15:56:15 +0200

On Mon, May 19, 2014 at 02:49:47PM +0100,
 Stephen Farrell <[email-masked]> wrote 
 a message of 11 lines which said:

> Still haven't had a chance to read the others, but that one looks
> good,

I did not spend a lot of time on draft-hallambaker-privatedns but it
frightens me a bit: very different from today's DNS and requiring to
understand a new technology.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 May 2014 10:23:42 -0400

> (except the last sentence of "security considerations").

These are architectural requirements. To talk about the tradeoffs we
have to have a proposed solution.

Private-DNS does provide protection against active attack but it is
optional. The design tradeoff is that the client has to authenticate
the service. Which is fairly straightforward when leveraging TLS. But
this does come at the cost of requiring the service to have a
credential (WebPKI, DANE, whatever).

The point about detaching the requirements discussion from the
implementation is that other people might have better ways to achieve
that requirement.

> personal information and we want to limit every leak.

This still looks to me to be more of an implementation than an
architectural requirement. But the ESA scheme had design requirements,
perhaps we could incorporate that into the discussion.

The other part of the ESA scheme was discussion of constraints. Those
are also pieces that can be factored out of the design. Things like
'low latency matters'.

> understand a new technology.

It isn't all that new. The architecture is mostly Kerberos. The key
exchange is a simple JSON/REST approach and the packet framing is just
a TLS style framing applied to a ticket based scheme.

The data that flows inside the messages is just plain old DNS with one
query per request. Bundling up multiple requests per packet isn't
making the protocol any more complex but allows the servers to be a
lot more efficient.

I do have a proposal that is a radical departure from DNS which is to
move to a meta-directory approach where the client asks the server to
return all the information required from all sources for discovery of
service X. Which includes sources like IP blacklists and domain
blocklists and PKIX CRLs, OCSP, etc.

But Private-DNS itself is very small. It is implementable on Arduino
class devices without taking up the whole memory space for the
implementation. Though you would probably want to modify the key
exchange so that you didn't need the whole TLS stack as well.