[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/
- [dnsext] DTLS alternative to DNS-Curve Phillip Hallam-Baker
- Re: [dnsext] DTLS alternative to DNS-Curve Tony Finch
- Re: [dnsext] DTLS alternative to DNS-Curve Phillip Hallam-Baker
- Re: [dnsext] DTLS alternative to DNS-Curve Tony Finch
- Re: [dnsext] DTLS alternative to DNS-Curve Phillip Hallam-Baker
- Re: [dnsext] DTLS alternative to DNS-Curve Nicholas Weaver
- Re: [dnsext] DTLS alternative to DNS-Curve Joe Abley
- Re: [dnsext] DTLS alternative to DNS-Curve Paul Vixie
- Re: [dnsext] DTLS alternative to DNS-Curve Paul Vixie