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

Jim Reid <jim@rfc1035.com> Sun, 07 March 2010 10:20 UTC

Return-Path: <jim@rfc1035.com>
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 CED7C28C0CE for <dnsop@core3.amsl.com>; Sun, 7 Mar 2010 02:20:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.944
X-Spam-Level:
X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=1.655, 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 6z4nmyO1++Uo for <dnsop@core3.amsl.com>; Sun, 7 Mar 2010 02:20:34 -0800 (PST)
Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 29AB228C12D for <dnsop@ietf.org>; Sun, 7 Mar 2010 02:20:33 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id BF05E154208B; Sun, 7 Mar 2010 10:20:18 +0000 (GMT)
From: Jim Reid <jim@rfc1035.com>
To: George Barwood <george.barwood@blueyonder.co.uk>
In-Reply-To: <2AA0F45200E147D1ADC86A4B373C3D46@localhost>
X-Priority: 3
References: <2AA0F45200E147D1ADC86A4B373C3D46@localhost>
Message-Id: <A76BB63E-F13B-4D90-BABB-89EB06C8E5F0@rfc1035.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 07 Mar 2010 10:20:17 +0000
X-Mailer: Apple Mail (2.936)
Cc: 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 10:20:38 -0000

On 7 Mar 2010, at 08:06, George Barwood wrote:

> If root-servers.net is unsigned, it's not possible for the resolver  
> to validate
> the set of root IP addresses

So what? If the served zones are signed, it simply doesn't matter if  
the address of a name server is spoofed or hijacked. The Bad Guy won't  
have the private keys, so will be unable to return answers which  
validate. In the context of a referral from the root, what matters is  
the signature over the TLD's RRset (and its KSKs), not the IP address  
of the root server or any signature that might or might not exist over  
its name.

> (a) An attacker can control every unsigned zone.
>
> (b) An attacker can monitor every request to a signed zone ( no  
> privacy ).
>
> (c) An attacker can deny service to any zone, on a selective basis.

It's not clear what point you're making or what your concerns are.  
None of these things listed above are remotely relevant. Apart from  
(a) which is hardly news: zones can be spoofed if they're not signed.  
[What next? Can we expect revelations about what bears do in the  
woods?] Privacy -- whatever that might mean -- has never been a design  
goal of DNS. Or Secure DNS for that matter. An eavesdropper can  
monitor *any* DNS request (signed or not) if they're close enough to  
the client or server. DoS attacks can and are mounted on any zone,  
whether or not they're signed. Meanwhile, in other news, water is  
discovered to be wet and fire is proven to be hot.

> Apparently there are currently no plans to sign root-servers.net

There's no point doing that IMO until .net is signed and there's a  
single chain of trust from root-servers.net to the One True Trust  
Anchor, the signed root. If the zone was to be self-signed, that would  
mean yet another TA would need to be embedded and maintained in  
validator configurations. Which creates more failure modes and scope  
for errors. And since validating the answers for root-servers.net will  
rarely if ever matter, adding that TA would be a lot of risk for  
almost no reward.