Subject: [dns-privacy] DTLS and OpenSSL Heartbleed bug

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 13 Apr 2014 08:34:46 -0400

There are many lessons that can be drawn from Heartbleed but one of
the most important is that complexity is the enemy of security and
general platforms have a tendency to become rather complex.

Which is one of the reasons why I have been rather suspicious of the
'just use DTLS' approach. Building on DTLS means importing all the
current and future complexity of TLS.

That seems rather a lot of overhead when all we need to do at the DNS
layer is to take a message M, encrypt it under a key and plonk a MAC
code on the end.

I know that the counter argument is that 'TLS is a known quantity, 20
years have gone into development'. But like the argument that 'open
source is better because anyone can review' we are seeing that its not
necessarily true. Code can get worse over time as well as better.

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

---

From: Rubens Kuhl <[email-masked]>
Date: Sun, 13 Apr 2014 09:45:17 -0300

> layer is to take a message M, encrypt it under a key and plonk a MAC

What about “Just use QUIC” ? It might have a better future with DNS than DTLS. 

> necessarily true. Code can get worse over time as well as better.

Open source is still better because anyone can review. But code get worse with time, either closed or open source, unlike wine. 

Rubens

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 13 Apr 2014 09:16:39 -0400

> What about “Just use QUIC” ? It might have a better future with DNS than DTLS.

QUIC is a replacement for TCP and it has a lot of merit for
applications where requests can be larger than a packet.

If the request will fit into one packet and the number of response
packets is small enough, the simplest approach is one UDP request
packet and multiple response packets. That means servers are
completely stateless and we can use anycast etc.

What might be rather surprising is that we can fit a complex DNS
transaction into one request packet, for example, to resolve
http://www.example.com/ we might want to do the following lookups:

www.example.com ? A
www.example.com ? AAAA
_http._tcp.www.example.com ? SRV
_http._tcp.www.example.com ? POLICY

Although the DNS protocol allows for multiple queries per request,
this doesn't quite work because there is no way to specify which
response code matches which query. So the simplest approach turns out
to be to encode these as four separate DNS queries. But even with that
overhead, we can fit all four queries above plus a MAC and a key
identifier into one 1400 byte request packet.

The nice thing about this is that it means support for the secure DNS
actually reduces the load on the server. Instead of making at least
two separate queries (A, AAAA) there is a single query. Since the
crypto overhead is negligible (its all symmetric key), this is almost
certainly a net win as most servers are I/O and transaction bound
rather than CPU bound.

> Open source is still better because anyone can review. But code get worse with time, either closed or open source, unlike wine.

These arguments are only problematic when people think 'A allows B'
means 'A therefore B'.

---

From: Rubens Kuhl <[email-masked]>
Date: Sun, 13 Apr 2014 13:01:08 -0300

> applications where requests can be larger than a packet.

“is a replacement for” is a judgement of suitability. Over the years I heard some people saying DNS should have used TCP with built-in scalability for large recursive and authoritative servers, so may be QUIC is quick enough to allow usage in the DNS world. If people converge on replace TCP with QUIC too that’s fine, but being useful for TCP is not a factor into using in DNS or not. 

> completely stateless and we can use anycast etc.

Stateless is a good thing, but a bit of state can be tolerated if it’s used for a high steady request volume. For instance, a Google 8.8.8.8 recursive server, even just one of the servers, likely keeps requesting Alexa-100 authoritative servers 24x7 without mercy. Requiring state would be bad, but allowing state where it justifies would be fine by me. 

Reverting to TCP due to multiple response packets, like is done today, really isn’t a good criteria, but query rate would be. Want a less than x queries / minute ? Do totally stateless. Want more than that ? State is required. We would get rid of one of  the DDoS vectors that exist today (high amplification attacks from a low number of fast compromised machines). 

> certainly a net win as most servers are I/O and transaction bound

Either with DTLS, QUIC or something else, that would be a sound design to have. 

Rubens

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 13 Apr 2014 20:01:30 +0300

> certainly a net win as most servers are I/O and transaction bound

There's also another factor to consider: Memory use. Specifically,
how much memory "sessions" that aren't currently being prcessed,
but which need to be able to bring to service in 0 RTT use.

I have no idea how DTLS would fare here...

Also, agreed that DTLS is a serious mess (and I think it is going to get
even worse).

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 13 Apr 2014 13:01:36 -0400

> Stateless is a good thing, but a bit of state can be tolerated if it’s used for a high steady request volume. For instance, a Google 8.8.8.8 recursive server, even just one of the servers, likely k…

Well you might have a point... But the people who have the problem
with latency are the google who want to shave it to the very minimum
possible. And they would be the main constituency for QUIC.

> Reverting to TCP due to multiple response packets, like is done today, really isn’t a good criteria, but query rate would be. Want a less than x queries / minute ? Do totally stateless. Want more t…

The way I avoid the DDoS attack is to authenticate requests so they
only get a response if there is a valid ticket. Amplification attacks
are no longer an issue.

---

From: John Heidemann <[email-masked]>
Date: Sun, 13 Apr 2014 21:43:21 -0700

On Sun, 13 Apr 2014 20:01:30 +0300, Ilari Liusvaara wrote: 
>...

A couple of comments:

- it seems to me like memory use is the biggest constraint if you're
running a server, and latency for the clients.

- unfortunately these conflict with each other: you reduce latency by
  keeping connections open and reusing them, but that increases memory
  use at servers

- We've done some studies about memory use for TCP+TLS, with real traces
  from several several different types of servers.  See
http://www.isi.edu/~johnh/PAPERS/Zhu14a.html for the tech report.
(We'd love comments and feedback!)

- the high order bit from the study is that with very conservative
  (i.e., short) timeouts, and with TCP+TLS from stub to recursive and
  TCP only from recursive to authoritative, we see ~21% greater latency
  and 9GB of state at the recursive resolver.  You can tweak the numbers
  to get different trade-offs if you prefer.

Both of these are more than current UDP, but both are, I think,
"reasonable".

And fortunately, DNS is embarrassingly parallel, so one can easily
increase server capacity by buying more servers.

About specific protocols:

- we took the most conservative choice: TCP and TLS.  Heartbleed shows
  us subtle bugs are possible, but IMHO better something the community
  has been studying for years and years than something hand-rolled,
  or something less well examined.

- Although not a privacy issue, I think DNS over TCP is a really
  interesting method to address other (non-privacy-related) security
  questions, like reducing DNS amplification attacks, and removing the
  endless debates about "change X will overflow packet size Y and cause
  subtle problem Z to W percent of users".  (IMHO, that debate has
  subtly distorted a number of policy discussions, like keysize choices.
  I'd just like to sidestep all that.)  Details are in the tech report;
  I don't want to get off-topic wrt dns-privacy.

- I think UDP+DTLS vs. TCP+TLS is an interesting open question.  It's
  not obvious to me that DTLS helps that much, as you still do a
  standard TLS handshake (just over UDP).  And I'm admiring of TCP for
  other reasons (see the prior bullet).  But I think a prudent step
  would be to advance TCP+TLS and then see if the same model also
  applies to UDP+DTLS, if we can articulate the compelling advantages of
  DTLS.

   -John Heidemann

---

From: Florian Weimer <[email-masked]>
Date: Sun, 20 Apr 2014 20:39:33 +0200

> (We'd love comments and feedback!)

Did you attempt to filter out garbage queries from your replay data?
Especially for the B root, I expect sources that would never be able
to complete a three-way handshake because they use incorrect IP
sources addresses.  I'm not sure in which direction garbage queries
tilt the numbers.

The stub resolver performance for classic DNS seems to be too good to
be true, partly due to the PlanetLab bias (as youn note)—or it
measures RRTs to some local non-recursive cache: many access
technologies have RTTs to the first IP hop that exceed 5 ms, and you
still have to reach the ISP resolver from there.  I wonder if it is
possible to obtain better data by triggering a cascade of name
resolutions from web browsers and try to tell upstream cache miss rate
from local stub cache miss rate.

> Both of these are more than current UDP, but both are, I think,

And these numbers are quite impressive because the classic DNS
baseline you've established seems a bit rosy to me.

In any case, interesting work.  Compared to DTLS (or any home-grown
protocol), the advantage of TLS over TCP is that we have extensive
experience in dealing with various kinds of network anomalies, much of
which would likely apply directly to protecting DNS infrastructure.

---

From: John Heidemann <[email-masked]>
Date: Tue, 22 Apr 2014 23:18:12 -0700

>> (We'd love comments and feedback!)

Thanks for the comments.

>sources addresses.  I'm not sure in which direction garbage queries

You mean queries with spoofed IP source addresses?
AFAIK our UDP data does not give us enough information to differentiate
actual from spoofed source IP addresses.

>baseline you've established seems a bit rosy to me.

Figure 9 looks at "local" (=5ms) and "public" (=20ms) (first-hop)
recursive resolvers.  If you you think 5ms is too low, you can consider
the 20ms numbers.  That moves the ~21% to ~39%.

>which would likely apply directly to protecting DNS infrastructure.

Thanks.  Our goal was to leverage TLS+TCP experience.

   -John