[dnsext] DTLS alternative to DNS-Curve

Phillip Hallam-Baker <hallam@gmail.com> Thu, 16 September 2010 16:58 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 D78203A6810; Thu, 16 Sep 2010 09:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.282
X-Spam-Level:
X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 yF0do9Gjm53o; Thu, 16 Sep 2010 09:58:00 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8AAF3A6832; Thu, 16 Sep 2010 09:57:56 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OwHgQ-000EsG-CE for namedroppers-data0@psg.com; Thu, 16 Sep 2010 16:51:38 +0000
Received: from mail-wy0-f180.google.com ([74.125.82.180]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <hallam@gmail.com>) id 1OwHgM-000Es0-Ma for namedroppers@ops.ietf.org; Thu, 16 Sep 2010 16:51:35 +0000
Received: by wyb40 with SMTP id 40so2049512wyb.11 for <namedroppers@ops.ietf.org>; Thu, 16 Sep 2010 09:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=z6a8doz492fumjw0UbWjAUXjhnjeiCHShPSTIoEVBsk=; b=YwGITHJc3Qu1pexrqnZZViHjxheg/TaMV67aSrFSGmPQaX6QLcAu2uvej7NYFd7eF9 IT7qv2oThcqiyH+nVqQbBtSYPXSYfiV+rw/rF8cDs3xGc/U6Tsf+BT+l9JPGkmmrI7R4 v8JGM3qjyvTgDDH0A6VZh5g5WAdWL3d00EtjM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Tk5Bmn2fR2qOT90G6mxKHbiWRqzqmNVuP4oBg07uRio8mnb4iB8WDVd/S41ffSv0jy DyaHN3twZ0eR24JRrPCa3zOOEfYDFXq0ncBHZfRuZa2Mgs4UBjZkgvJQ9oMTO4PTyfyG 4dxNzO9d8/LAb4A2ts6/gOSu5DDgt+Qhu2TMQ=
MIME-Version: 1.0
Received: by 10.227.147.142 with SMTP id l14mr2944523wbv.214.1284655891158; Thu, 16 Sep 2010 09:51:31 -0700 (PDT)
Received: by 10.216.163.195 with HTTP; Thu, 16 Sep 2010 09:51:31 -0700 (PDT)
Date: Thu, 16 Sep 2010 12:51:31 -0400
Message-ID: <AANLkTin2xY+cAck+3sWcn8hibDrZbXLzttznGM9sRQz+@mail.gmail.com>
Subject: [dnsext] DTLS alternative to DNS-Curve
From: Phillip Hallam-Baker <hallam@gmail.com>
To: namedroppers <namedroppers@ops.ietf.org>
Content-Type: multipart/alternative; boundary="00163630fb7f0d1562049063421d"
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/>

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/