Re: DNSCurve vs. DNSSEC - FIGHT!

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Fri, 26 February 2010 09:49 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C0B28C13E for <ietf@core3.amsl.com>; Fri, 26 Feb 2010 01:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.468
X-Spam-Level:
X-Spam-Status: No, score=0.468 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 Xo+hGIQcLGrw for <ietf@core3.amsl.com>; Fri, 26 Feb 2010 01:49:22 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 5C53D28C11A for <ietf@ietf.org>; Fri, 26 Feb 2010 01:49:22 -0800 (PST)
Received: (qmail 82021 invoked from network); 26 Feb 2010 10:54:36 -0000
Received: from bmdk2060.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (203.180.16.60) by necom830.hpcl.titech.ac.jp with SMTP; 26 Feb 2010 10:54:36 -0000
Message-ID: <4B879974.9070603@necom830.hpcl.titech.ac.jp>
Date: Fri, 26 Feb 2010 18:50:44 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: Florian Weimer <fweimer@bfk.de>
Subject: Re: DNSCurve vs. DNSSEC - FIGHT!
References: <874c02a21002231826y613b9f97ya83740ba240f7bf9@mail.gmail.com> <ABE739C5ADAC9A41ACCC72DF366B719D02C29D87@GLKMS2100.GREENLNK.NET> <a123a5d61002240700i4a68367tf901b91265f79da1@mail.gmail.com> <1267039830.9710.11106.camel@shane-asus-laptop> <alpine.LSU.2.00.1002242049510.16971@hermes-2.csi.cam.ac.uk> <p06240819c7ab46c7fbf9@[10.20.30.158]> <4B859F15.9080106@acm.org> <4B85B7E5.1000104@necom830.hpcl.titech.ac.jp> <201002242347.o1ONlt7L023898@drugs.dv.isc.org> <4B85BF52.7030004@necom830.hpcl.titech.ac.jp> <82fx4po0nb.fsf@mid.bfk.de> <4B87930B.2070400@necom830.hpcl.titech.ac.jp> <82zl2wgx76.fsf@mid.bfk.de>
In-Reply-To: <82zl2wgx76.fsf@mid.bfk.de>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2010 09:49:23 -0000

Florian Weimer wrote:

>>No, it is not expected that gtld servers will become
>>"???????????????????????????????????????????????????.gtld-servers.net",
>>only to cause message size overflow.

> Wouldn't compression kick in if they shared keys (assuming that
> DNSCurve doesn't sift the key from only the first label), making the
> overhead negligible?

There are several ways, such as anycasting, to overcome the problem.
However, they will require wide distribution of secret keys.

Anyway, my point is that there was no expectation.

Another evidence is lack of the concept of "root key" and other
things. If relying on security of root and other zones, which are
not really secure, was seriously considered, there should be
provisions for more complex mechanisms such as key roll over to
make the system a little less insecure.

						Masataka Ohta