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

David Wilson <David.Wilson@isode.com> Mon, 08 June 2009 19:55 UTC

Return-Path: <David.Wilson@isode.com>
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 0383E3A6E17 for <asrg@core3.amsl.com>; Mon, 8 Jun 2009 12:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 EUFYRpGwet2F for <asrg@core3.amsl.com>; Mon, 8 Jun 2009 12:55:41 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 861133A6E14 for <asrg@irtf.org>; Mon, 8 Jun 2009 12:55:41 -0700 (PDT)
Received: from [192.168.50.2] (82-44-14-207.cable.ubr04.mort.blueyonder.co.uk [82.44.14.207]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <Si1sZgAh5FXE@rufus.isode.com>; Mon, 8 Jun 2009 20:54:15 +0100
From: David Wilson <David.Wilson@isode.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <4A29EC02.6000807@necom830.hpcl.titech.ac.jp>
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>
Organization: Isode Limited
Date: Mon, 08 Jun 2009 20:54:09 +0100
Message-Id: <1244490849.2822.21.camel@bravo.isode.net>
X-Mailer: Evolution 2.26.2 (2.26.2-1.fc11)
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: 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: Mon, 08 Jun 2009 19:55:42 -0000

On Sat, 2009-06-06 at 13:09 +0900, Masataka Ohta wrote:
> David Wilson wrote:
> 
> > However, I think there is some difference in the way people are using
> > some terms.
> 
> According to the terminology of David Clark, PKI including DNSSEC
> is not secure end to end.

DNSSEC provides two things. Firstly, it provides the means to digitally
sign RRsets. This provides data origin authentication and data
integrity. As this operates at the DNS application layer, this is
clearly "end to end" within David Clark's terminology. It does not rely
on any security services in the lower communication layers (in the way
that, for instance, relying on TCP would).

This origin authentication and integrity is precisely what is required
to avoid the DNS cache poisoning which is the kind of vulnerability
which prompted this discussion.

This aspect of DNSSEC does not require the use of any PKI. A security
aware resolver can obtain by some out-of-band means the public signing
key for some "island of security", and choose to trust that key.

However, such bilateral arrangements do not scale to the Internet. So,
DNSSEC provides a means for an Authentication Chain, to use the specific
DNSSEC term. A signed zone can authenticate the key of a child zone.
There is a chain here. However, it is of a significantly different
character to a communication network. Whether it is "end to end" or not,
is for a different discussion.

> 
> > "End-to-end" security means that the security of that data item does not
> > depend on the trustworthiness of any intermediate node, or channel.
> 
> According to the terminology of David Clark, certificate authorities
> are intermediate nodes.
> 
> If you have different terminology, use it outside of the Internet
> community but not within.

I get the impression from you that DNSSEC is to be disregarded because
it is not "end to end". However, the opinion of "the Internet community"
as regards DNSSEC has been made clear in the last few days, given these
announcements:

http://www.nist.gov/public_affairs/releases/dnssec_060309.html

http://pir.org/index.php?db=content/Website&tbl=ORG_Advantage&id=2

http://www.networkworld.com/news/2009/022409-verisign-dns-security.html?hpg1=bn

If the Internet community agrees with you that DNSSEC is not "end to
end", then this does not seem to divert them from implementing it.

best regards

David