Re: [Asrg] DNSSEC is NOT secure end to end

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 10 June 2009 22:55 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376D33A6B4A for <asrg@core3.amsl.com>; Wed, 10 Jun 2009 15:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.713
X-Spam-Level: *
X-Spam-Status: No, score=1.713 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643]
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 dFg7a5BW1Mih for <asrg@core3.amsl.com>; Wed, 10 Jun 2009 15:55:25 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 3997F3A68AD for <asrg@irtf.org>; Wed, 10 Jun 2009 15:55:25 -0700 (PDT)
Received: (qmail 67251 invoked from network); 11 Jun 2009 00:28:25 -0000
Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 11 Jun 2009 00:28:25 -0000
Message-ID: <4A3039BC.1050608@necom830.hpcl.titech.ac.jp>
Date: Thu, 11 Jun 2009 07:54:52 +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: Andrew Sullivan <ajs@shinkuro.com>
References: <200905302032.n4UKVxaZ048822@givry.fdupont.fr> <4A21C0CB.8070409@necom830.hpcl.titech.ac.jp> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8661@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <4A252B54.6020508@necom830.hpcl.titech.ac.jp> <1244061519.2778.62.camel@bravo.isode.net> <4A29EC02.6000807@necom830.hpcl.titech.ac.jp> <1244490849.2822.21.camel@bravo.isode.net> <4A2DA4C8.2000304@necom830.hpcl.titech.ac.jp> <1244535420.2760.64.camel@bravo.isode.net> <4A2EFBCE.5000502@necom830.hpcl.titech.ac.jp> <20090610165911.GH33231@shinkuro.com>
In-Reply-To: <20090610165911.GH33231@shinkuro.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: David Wilson <David.Wilson@isode.com>, Anti-Spam Research Group - IRTF <asrg@irtf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [Asrg] DNSSEC is NOT secure end to end
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2009 22:55:26 -0000

Andrew Sullivan wrote:

>>>With DNSSEC, a security aware resolver will want to check the signature.

>>Except for glue A.
 
> That's not a vector for attack.

Glue is the vector for most, if not all, attacks including
Kaminsky's and DNSSEC with forged certificates.

> If you are validating data, why would
> you not follow the chain to the glue record (secured on each side of
> _that_ cut by the DS/DNSKEY pairs) and validate the signature on the
> authoritative data you get?

Following the chain over a forged certificate to confirm
forged data have valid signatures?

Or, what if the glue is inside a grand child zone on which no
nameservers are responding?

When DNSSEC was designed, I pointed out several detailed
but fatal problems including that glue can not be secured.
The WG had a different fantasy. The WG wasted about 10 years
for experimental deployment only to confirm that I have been
perfectly correct and the protocol was modified.

So, you don't have to waste yet another 10 years only to
reconfirm it.

Just accept the current DNSSEC protocol:

>>>With DNSSEC, a security aware resolver will want to check the signature.
>>Except for glue A.

which makes DNSSEC as insecure as plain old DNS.

						Masataka Ohta