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

Jim Reid <jim@rfc1035.com> Mon, 08 March 2010 00:37 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 A3D5C3A67F4 for <dnsop@core3.amsl.com>; Sun, 7 Mar 2010 16:37:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.036
X-Spam-Level:
X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.563, 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 NkpZf+vubCZn for <dnsop@core3.amsl.com>; Sun, 7 Mar 2010 16:37:50 -0800 (PST)
Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 3C8AB3A67EF for <dnsop@ietf.org>; Sun, 7 Mar 2010 16:37:50 -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 79D6D154208B; Mon, 8 Mar 2010 00:37:52 +0000 (GMT)
From: Jim Reid <jim@rfc1035.com>
To: George Barwood <george.barwood@blueyonder.co.uk>
In-Reply-To: <F7C1873BC5BD40988CEC30A6BC67CDDF@localhost>
X-Priority: 3
References: <2AA0F45200E147D1ADC86A4B373C3D46@localhost> <A76BB63E-F13B-4D90-BABB-89EB06C8E5F0@rfc1035.com> <4B93A046.4020209@necom830.hpcl.titech.ac.jp> <B98D66FF-E4EB-47BE-8302-D4C6D3E70238@icsi.berkeley.edu> <F7C1873BC5BD40988CEC30A6BC67CDDF@localhost>
Message-Id: <90917F7B-F093-4385-ACEF-135AA2F86860@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: Mon, 08 Mar 2010 00:37:51 +0000
X-Mailer: Apple Mail (2.936)
Cc: IETF DNSOP WG <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: Mon, 08 Mar 2010 00:37:51 -0000

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

>> 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.
>
> The dependency on .net for the root name servers seems strange to me.

Get over it.

> Intuitively, I should not have to trust .net to get a validated set  
> of root name servers.

You only need to trust the signatures over the signed delegations from  
root servers, not the signatures (if any) over the address records for  
the zone's name servers. This has been explained to you already.  
Spoofed IP addresses for the root's name servers -- either through DNS  
or evil routing trickery -- won't matter once the zone is signed for  
real. An impostor won't be able to sign their bogus root zone because  
they won't have access to the actual keys. Anything for the root  
that's returned from these spoofed addresses simply won't validate.

> This doesn't cure all the security ills of the world, but does  
> constitute a small improvement in security, especially for TLDs that  
> have not yet been signed.

Nope. If some TLD isn't signed it can be spoofed regardless of whether  
or not the root (or root-servers.net) is signed. The same is true for  
any unsigned zone that lives user a trust anchor which is used for  
validation.

> If TLDs also do not sign their name server domains, then a single  
> blind spoof packet allows an attacker to intercept all the traffic  
> for a resolver.

Yawn. That's still true whether or not root-servers.net is signed and  
the resolver validates that zone's signatures. Or if the zone isn't  
signed. See above.

> Even the root server traffic is somewhat sensitive - it can often be  
> what some end-user has just typed, which could well be confidential,  
> such as a password ( e.g. they think they are entering a password,  
> but are actually typing into an address bar ).

So don't do that. Duh!

What point are you trying to make here or ascribe to the use or non- 
use of DNSSEC? If people put crap in their DNS queries, that crap will  
more than likely get presented to external name servers. DNSSEC is not  
and never has been about confidentiality. Either of DNS data or  
queries. If fail to see how stupid end user behaviour with web  
browsers that leaks sensitivie data can have anything to do with  
DNSSEC deployment at all. Or why you raise this non-issue on this list.