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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 03 June 2009 07:52 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 48E4B3A6AD2 for <asrg@core3.amsl.com>; Wed, 3 Jun 2009 00:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[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 aoIv1-8mei-2 for <asrg@core3.amsl.com>; Wed, 3 Jun 2009 00:52:57 -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 C91633A6AC3 for <asrg@irtf.org>; Wed, 3 Jun 2009 00:52:56 -0700 (PDT)
Received: (qmail 97166 invoked from network); 3 Jun 2009 09:23:36 -0000
Received: from bmdk3152.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (203.180.17.152) by necom830.hpcl.titech.ac.jp with SMTP; 3 Jun 2009 09:23:36 -0000
Message-ID: <4A262BAD.6040802@necom830.hpcl.titech.ac.jp>
Date: Wed, 03 Jun 2009 16:52:13 +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: Christian Huitema <huitema@windows.microsoft.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> <4A253289.3020000@connotech.com> <8EFB68EAE061884A8517F2A755E8B60A1EF83F8A38@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1EF83F8A38@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 03 Jun 2009 12:09:27 -0700
Cc: Thierry Moreau <thierry.moreau@connotech.com>, Francis Dupont <Francis.Dupont@fdupont.fr>, 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, 03 Jun 2009 07:52:57 -0000

Christian Huitema wrote:

> NAT routers come to mind. DNSSEC
> is immune to such attacks, a big advantage in practice.

I'm afraid DNSSEC and some NAT interact terribly.

> Also, it is actually possible to improve on DNSSEC by introducing
>  additional knowledge. If two domains have an establish relation,
> their servers can memorize the relevant public keys. If a host
> has a relation with a domain, it can memorize that domain's
> public key. This kind of "peer-to-peer" improvement makes the
> domain-to-domain or host-to-domain DNSSEC service immune to
> attacks by nodes higher in the hierarchy.

Do you know that the paper particularly discusses on revocation?

It is written in the paper that:

	It can happen that a user loses his private key (the value
	that goes with the given public key) through inadvertence or
	theft; alternatively, a user may become unworthy in some way
	relevant to the purpose for which the certificate has been
	issued. Under such circumstances, the certificate authority
	(third party) would want to revoke the certificate. How can
	this be known?

Your "improvement" makes the entire system more complex only to
introduce new difficulties for revocation.

						Masataka Ohta