Re: [DNSOP] Should be signed

"George Barwood" <> Sun, 07 March 2010 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 802713A8F99 for <>; Sun, 7 Mar 2010 07:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.996
X-Spam-Level: *
X-Spam-Status: No, score=1.996 tagged_above=-999 required=5 tests=[AWL=1.401, BAYES_00=-2.599, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vve49mdZAIYN for <>; Sun, 7 Mar 2010 07:57:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C85813A8C78 for <>; Sun, 7 Mar 2010 07:57:40 -0800 (PST)
Received: from [] (helo=anti-virus03-08) by with smtp (Exim 4.52) id 1NoIrN-0008QU-F6; Sun, 07 Mar 2010 15:57:41 +0000
Received: from [] (helo=GeorgeLaptop) by with esmtpa (Exim 4.52) id 1NoIrM-0003jh-TO; Sun, 07 Mar 2010 15:57:40 +0000
Message-ID: <3F69F937B00E45FBA6A2ACD24FA4AFA6@localhost>
From: George Barwood <>
To: Jim Reid <>
References: <2AA0F45200E147D1ADC86A4B373C3D46@localhost> <>
Date: Sun, 07 Mar 2010 15:57:30 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: Re: [DNSOP] Should be signed
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Mar 2010 15:57:42 -0000

----- Original Message ----- 
From: "Jim Reid" <>
To: "George Barwood" <>
Cc: <>
Sent: Sunday, March 07, 2010 10:20 AM
Subject: Re: [DNSOP] Should be signed

> On 7 Mar 2010, at 08:06, George Barwood wrote:
>> If 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?] 

Prevention of spoofing is a goal of DNSSEC.
However, if a zone ( such as ) is not signed, spoofing is not prevented.
This has negative consequences, and weakens the protection that DNSSEC offers.

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

Yes, but I'm talking about blind spoofing attacks, where a single successful spoof
results in the attacker gaining a lot, and which can be stopped by signing

> 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
> There's no point doing that IMO until .net is signed and there's a  
> single chain of trust from to the One True Trust  
> Anchor, the signed root. 

I hadn't considered that. The dependency on .net is perhaps a little odd.
A more logical set of name server names might be simply


so that the dependency is removed. There may be objections to this.

> 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 will  
> rarely if ever matter, adding that TA would be a lot of risk for  
> almost no reward.

I agree that there is little point in signing root-servers if it can not
be validated without configuring a special trust anchor.
Of course another solution to that is to sign .net

-- George