Re: [DNSOP] Should root-servers.net be signed

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Sun, 07 March 2010 15:31 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD3C3A914F for <dnsop@core3.amsl.com>; Sun, 7 Mar 2010 07:31:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.959
X-Spam-Level:
X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 QX5ETgcJnb1D for <dnsop@core3.amsl.com>; Sun, 7 Mar 2010 07:31:09 -0800 (PST)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 481D33A8708 for <dnsop@ietf.org>; Sun, 7 Mar 2010 07:31:09 -0800 (PST)
Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o27FVAAx024298; Sun, 7 Mar 2010 07:31:10 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <4B93A046.4020209@necom830.hpcl.titech.ac.jp>
Date: Sun, 07 Mar 2010 07:31:10 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B98D66FF-E4EB-47BE-8302-D4C6D3E70238@icsi.berkeley.edu>
References: <2AA0F45200E147D1ADC86A4B373C3D46@localhost> <A76BB63E-F13B-4D90-BABB-89EB06C8E5F0@rfc1035.com> <4B93A046.4020209@necom830.hpcl.titech.ac.jp>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
X-Mailer: Apple Mail (2.1077)
Cc: George Barwood <george.barwood@blueyonder.co.uk>, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, dnsop@ietf.org
Subject: Re: [DNSOP] Should root-servers.net be signed
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Mar 2010 15:31:10 -0000

On Mar 7, 2010, at 4:47 AM, Masataka Ohta wrote:

> Jim Reid wrote:
> 
>> The Bad Guy won't have the private keys,
> 
> Wrong.
> 
> While the Bad Guy as an ISP administrator won't have the private
> keys, the Bad Guy as a zone administrator will have the private
> keys.
> 
> That is, DNSSEC is not secure cryptographically, which is another
> reason why not to deploy DNSSEC.

I don't see what your argument here is.

DNSSEC is a "PKI in disguise", and like ANY PKI, you still depend on trust up the heirarchy, as that is exactly how a PKI is supposed to work: One level up says something about the levels down.

But DNS has ALWAYS depended on trust-up-the-heirarchy anyway, so this aspect of DNSSEC doesn't increase the level of trust required in DNS, it just only codifies it in cryptographic terms so there is no trust (that isn't made explicit) beyond the scope up the heirarchy.

This is actually why DNSSEC is useful: it IS a PKI, who's heirarchical nature already matches the existing heirarchy on naming.  In the end, signing A records is useless.  But signing TXT and CERT records will be incredibly useful, if validated on the end-host application.

Additionally, since it would be end-host application validating those signatures, it can enforce that "there must exist a signature path from the root" (aka, it is actually a PKI). [1]


But since unless you manually or do some other finagling can't easily establish trust if you don't have trust above, root-servers.net should only sign after .net is signed at this point in the rollout.  And any PROPER useage of DNSSEC won't rely on root-servers.net ever being signed at all, because its only on the name path for resolvers.


[1] Thus, you don't have to worry about also needing the name path for the resolvers signed or the DOS attack by a MitM stripping signatures as part of their changing DNS results.