Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Mon, 01 March 2010 22:14 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 76D9228C1DA for <ietf@core3.amsl.com>; Mon, 1 Mar 2010 14:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.457
X-Spam-Level:
X-Spam-Status: No, score=0.457 tagged_above=-999 required=5 tests=[AWL=0.547, 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 1JuDa0ZiHRgj for <ietf@core3.amsl.com>; Mon, 1 Mar 2010 14:14:51 -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 1420428C1BE for <ietf@ietf.org>; Mon, 1 Mar 2010 14:14:50 -0800 (PST)
Received: (qmail 77376 invoked from network); 1 Mar 2010 23:07:41 -0000
Received: from softbank219001188004.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 1 Mar 2010 23:07:41 -0000
Message-ID: <4B8C3988.3040600@necom830.hpcl.titech.ac.jp>
Date: Tue, 02 Mar 2010 07:02:48 +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: Wassim Haddad <wmhaddad@gmail.com>
Subject: Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
References: <874c02a21002231826y613b9f97ya83740ba240f7bf9@mail.gmail.com> <4B85BF52.7030004@necom830.hpcl.titech.ac.jp> <c331d99a1002241619y47f91f50g4433a7233350dc74@mail.gmail.com> <4B85DBCA.2060407@necom830.hpcl.titech.ac.jp> <4B862D03.7060602@gnutls.org> <4B863571.40604@necom830.hpcl.titech.ac.jp> <a123a5d61002250614h36c51a42xebb54c3cc340829d@mail.gmail.com> <alpine.LFD.1.10.1002251151010.1697@newtla.xelerance.com> <a123a5d61002251201k10b5305ai3aa226fc6b84a793@mail.gmail.com> <4B8C2DF8.5040206@necom830.hpcl.titech.ac.jp> <9a367ee31003011321q64e53d94taf7c7f4c324ef446@mail.gmail.com>
In-Reply-To: <9a367ee31003011321q64e53d94taf7c7f4c324ef446@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: Phillip Hallam-Baker <hallam@gmail.com>, 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: Mon, 01 Mar 2010 22:14:52 -0000

Wassim Haddad wrote:

>>I don't know what EV means, but anything human, including CA, is not
>>infallible, which is why PKI is insecure.

> => Can you please explain in few lines what would be your preference(s) for
> a solution to enable DNSsec?
> I apologize if you have already submitted a proposal about it which I must
> have missed... in which case, I would appreciate a pointer.

If you are talking about a technical mechanism not to cause message
size overflow beyond 512B even with 2048bit keys, the solution is
to use different RR types for different kind of keys, which I
proposed more than 15 yeas ago in draft-ohta-simple-dns-00:

   In general, data size for authentication is often as large as of 100
   bytes or more.  So, it is a bad idea to share a single RR type value
   between different authentication mechanisms, because querying them
   all will often break 512 byte limit of UDP query.  So, authentication
   algorithms are distinguished by RR type values, not by something like
   an algorithm type field.

It's crazy to share an RR type between ZSK and KSK.

For key roll over, different RR types should be used for even and
odd generations. You may also use elliptic curve cryptography,
though I don't prefer it.

But, later, I noticed fundamental fraud in PKI, against which no
technical solution exists. Note that separation of ZSK and KSK
was an impossible attempt make inherently insecure PKI less
insecure.

						Masataka Ohta