Subject: [dnsext] DTLS alternative to DNS-Curve

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Sep 2010 12:51:31 -0400

While I like the architectural approach of DNS-Curve for certain
applications, the realization is really not very sensitive to the existing
DNSSEC infrastructure. There is a lot of new protocol, a lot of new code to
write and test.

The specific field of interest to me is securing the connection between a
DNS client and a DNS resolver. In the traditional model the DNS resolver has
a trusted role but the connection between the client and resolver has
neither confidentiality nor integrity protections. In a secure environment I
want both.

TSIG is much closer to what I want. All I really want is either TSIG plus a
key exchange mechanism or TSIG plus confidentiality plus a key exchange
mechanism.

Any mechanism we use has to be capable of operating without server side
connection state. It is also helpful if the mechanism allows a limited form
of packet aggregation in case the added crypto data causes the responses to
exceed the MTU.

TLS already has a suitable key agreement mechanism and has a means of
establishing a ticket that contains the server side state. Reusing this
mechanism avoids the need to write any additional code in most cases since
most DNSSEC implementations are built on OpenSSL or on a platform like
Windows that includes a full SSL stack.

One option is to build a two phase scheme in which the key negotiation is
performed in one phase using TLS to a HTTPS server to establish a ticket.
That ticket can then be used to support a secure wrapper for the DNS request
and response.

Another option is to use DTLS. That might simplify coding further still when
using a library that already has DTLS. The downside is that we would not be
able to optimize the scheme to DNS and the result would be much more complex
in cases where DTLS is not already supported since we are only using a small
subset of that spec.

I don't have a concrete proposal of this type to make at the present time.
But if people are interested in this approach and want to work together on a
proposal, could they drop me a line?

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Sep 2010 19:26:08 +0100

> key exchange mechanism or TSIG plus confidentiality plus a key exchange

TKEY is DNS's key exchange mechanism.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Sep 2010 14:43:40 -0400

I think it would take a huge amount of effort to get RFC 2930 into an
acceptable state. It is ten years old and like many other DNSSEC drafts of
that vintage rather vague on details.

http://tools.ietf.org/html/rfc2930

This is really not much more than a RR format with a vague suggestion to use
GSSAPI.

I still need a ticket format to avoid a need for server side state.

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Sep 2010 20:05:30 +0100

> This is really not much more than a RR format with a vague suggestion to use

It is widely deployed:
http://technet.microsoft.com/en-us/library/cc961412.aspx

It does need extending to secure queries (as well as / instead of updates)
and to work outside the context of a kerberos realm.

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Sep 2010 16:20:30 -0400

It certainly works for updates and there is certainly a delta required to
use it for requests. My starting point for doing all this stuff was looking
at TKEY.

Now whether it is better to build on TKEY/GSSAPI or TLS/Ticket is something
we can argue about later. It is not out of the bounds of possibility that we
might want both. One of the problems of using DNS for anything at this point
is that some networks have firewalls that filter the DNS traffic and some
broadband providers intercept and redirect DNS traffic.

I think we probably agree that we can meet our requirements for servicing
client requests without going to DNSCurve and introducing a completely new
raft of crypto.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 16 Sep 2010 14:18:36 -0700

On Sep 16, 2010, at 1:20 PM, Phillip Hallam-Baker wrote:

>  One of the problems of using DNS for anything at this point is that some networks have firewalls that filter the DNS traffic and some broadband providers intercept and redirect DNS traffic.

Based on our insights from Netalyzr ( http://www.icir.org/vern/papers/netalyzr.imc2010.pdf )...

If you want your traffic unmolested, tunnel it over TCP 443 and use TLS: thats just about the only thing that's pretty much guaranteed to be unmolested.

For DNS in particular, there are a surprising number of boxes that molest traffic that it deems 'non-conforming' (11% of sessions): DNS packets works fine to an arbitrary host (actual blocking or proxying real DNS over UDP was surprisingly rare), but non-DNS over DNS gets brutally shot down by the network.  Often the network admins are completely unaware this is occurring.

Heck, there are plenty of middleboxes that stomp EDNS0 replies > 512B but < 1500B, and a few that just stomp EDNS0 period.

This is arguably one of the biggest problems with DNSCurve: it WILL get stomped on by middleboxes.

Things are probably a bit better about dealing with unknown type resource-records on-the-wire, but I won't know for sure for a couple of months (it in our enhanced test suite we are pushing out RSN), but the common NAT DNS proxies don't seem very good with unknown resource records (again, in our enhanced testing, but so far I'm two-for-two on the dinky NATs I'm using rejecting requests for an 'unknown' RTYPE (type 169, just grabbed that number for the experiment, AFAIK thats an unused RTYPE)).

And don't trust the recursive resolver.  Not only did we see malicious resolvers, and the now endemic NXDOMAIN wildcarding, but we also saw multiple ISPs that used DNS to MitM search engines (www.google.com, search.yahoo.com, www.bing.com) so that all search traffic is directed through an ISP controlled proxy.

Overall, this suggests the following:

New RTYPEs can be used, but reluctantly.  But it does make it much more tempting to push things into TXT records rather than using rare records that may be unused (eg, CERT) or creating new RTYPE, because there is less worry with TXT records being stomped on by the network or user's DNS infrastructure.

Changing the DNS 'packet format', yet keeping UDP port 53, however is a total no-go: use a different port # if you want something that won't parse to the wire as DNS.  Otherwise, it won't work.

---

From: Joe Abley <[email-masked]>
Date: Thu, 16 Sep 2010 19:33:36 -0400

On 2010-09-16, at 17:18, Nicholas Weaver wrote:

> New RTYPEs can be used, but reluctantly.

To me what you described is actually an argument to promote the use of new RTYPEs, not to discourage it.

Not seeing widespread of new RTYPEs in the wild is presumably what led to the entrenched belief that it's reasonable to filter on RTYPE in middleboxes. The way to stamp out this thinking is to reverse the trend.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Fri, 17 Sep 2010 05:06:56 +0000

> From: Joe Abley <[email-masked]>
> Date: Thu, 16 Sep 2010 19:33:36 -0400
> 

strong +1.

> Not seeing widespread of new RTYPEs in the wild is presumably what led to
> the entrenched belief that it's reasonable to filter on RTYPE in
> middleboxes. The way to stamp out this thinking is to reverse the trend.

yes.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 17 Sep 2010 05:54:01 +0000

> Date: Thu, 16 Sep 2010 19:26:08 +0100
> From: Tony Finch <[email-masked]>
> 

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01002.html