Re: [dnsext] DTLS alternative to DNS-Curve

Nicholas Weaver <nweaver@icsi.berkeley.edu> Thu, 16 September 2010 21:23 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2077C3A6A96; Thu, 16 Sep 2010 14:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.155
X-Spam-Level:
X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYHejHgZHVhj; Thu, 16 Sep 2010 14:23:09 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 457993A6A7C; Thu, 16 Sep 2010 14:23:09 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OwLqr-000FIK-A8 for namedroppers-data0@psg.com; Thu, 16 Sep 2010 21:18:41 +0000
Received: from taffy.icsi.berkeley.edu ([192.150.187.26]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <nweaver@icsi.berkeley.edu>) id 1OwLqo-000FHc-5w for namedroppers@ops.ietf.org; Thu, 16 Sep 2010 21:18:38 +0000
Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 5080836A420; Thu, 16 Sep 2010 14:18:37 -0700 (PDT)
References: <AANLkTin2xY+cAck+3sWcn8hibDrZbXLzttznGM9sRQz+@mail.gmail.com> <alpine.LSU.2.00.1009161925200.31356@hermes-2.csi.cam.ac.uk> <AANLkTikEq8KVQxzAo3e_RJOWbYvVGrXjLnVCooFs3H=q@mail.gmail.com> <alpine.LSU.2.00.1009162003370.31356@hermes-2.csi.cam.ac.uk> <AANLkTimD=Mcx-COzENWWd1GeESCW8hW189uRJE6eDanB@mail.gmail.com>
In-Reply-To: <AANLkTimD=Mcx-COzENWWd1GeESCW8hW189uRJE6eDanB@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
Message-Id: <02A6011E-033F-40E6-B937-49A56F6D48D1@icsi.berkeley.edu>
Content-Transfer-Encoding: quoted-printable
Cc: Nicholas Weaver <nweaver@icsi.berkeley.edu>, Tony Finch <dot@dotat.at>, namedroppers <namedroppers@ops.ietf.org>
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Subject: Re: [dnsext] DTLS alternative to DNS-Curve
Date: Thu, 16 Sep 2010 14:18:36 -0700
To: Phillip Hallam-Baker <hallam@gmail.com>
X-Mailer: Apple Mail (2.1081)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

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.