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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sun, 07 March 2010 13:55 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 075B93A8307 for <dnsop@core3.amsl.com>; Sun, 7 Mar 2010 05:55:47 -0800 (PST)
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 tmCHnF1iHhQy for <dnsop@core3.amsl.com>; Sun, 7 Mar 2010 05:55:45 -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 719493A6774 for <dnsop@ietf.org>; Sun, 7 Mar 2010 05:55:45 -0800 (PST)
Received: (qmail 85644 invoked from network); 7 Mar 2010 15:01:37 -0000
Received: from softbank219178199025.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.199.25) by necom830.hpcl.titech.ac.jp with SMTP; 7 Mar 2010 15:01:37 -0000
Message-ID: <4B93B03A.10304@necom830.hpcl.titech.ac.jp>
Date: Sun, 07 Mar 2010 22:55:06 +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: Jim Reid <jim@rfc1035.com>
References: <2AA0F45200E147D1ADC86A4B373C3D46@localhost> <A76BB63E-F13B-4D90-BABB-89EB06C8E5F0@rfc1035.com> <4B93A046.4020209@necom830.hpcl.titech.ac.jp> <FBF55545-A279-4AA1-ACD3-E2EBBCEF5AFC@rfc1035.com>
In-Reply-To: <FBF55545-A279-4AA1-ACD3-E2EBBCEF5AFC@rfc1035.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: George Barwood <george.barwood@blueyonder.co.uk>, 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 13:55:47 -0000

Jim Reid wrote:

>> 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.

> True,

Good enough.

> This claim is ridiculous. Unless someone uncovers a fundamental flaw  in 
> public key cryptography,

The fundamental flow of public key cryptography for its, wrongly
claimed, cryptographical security is that trusted third parties
are not cryptographically secure, which you have already said
"True,".

As you can see that the Bad Guy as a zone administrator will
have the private keys, there is no cryptographical security,
here.

> DNSSEC is secure cryptographically  provided 
> the private key(s) remain private.

The provision is not cryptographical.

> Now some people may (or may not) trust a third party to manage their  
> keys and zone signing for them. That's their choice.

Have you ever heard about such thing as monopoly?

With monopoly, consumers do not have any choice, which is the case
with DNS.

You are totally bound to "." and many are to ".com".

> It's just one of  
> the many trade-offs that have to be considered in any sort of security  
> system. For some, a private key held by a third party may well meet or  
> exceed their security requirements.

That there are many operational trade-offs means that the security
is not cryptographic. 

						Masataka Ohta