Re: How do we get the whole world to upgrade to DNSSEC capable resolvers?

bmanning@vacation.karoshi.com Sat, 26 July 2008 17:07 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26543A68CE; Sat, 26 Jul 2008 10:07:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.37
X-Spam-Level:
X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 TYZfzzMYfS+M; Sat, 26 Jul 2008 10:07:58 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3CDF3A67AB; Sat, 26 Jul 2008 10:07:58 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KMn9d-000D81-B5 for namedroppers-data@psg.com; Sat, 26 Jul 2008 17:02:01 +0000
Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <bmanning@karoshi.com>) id 1KMn9O-000Cvw-Tl for namedroppers@ops.ietf.org; Sat, 26 Jul 2008 17:01:49 +0000
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6QGxfup029204; Sat, 26 Jul 2008 16:59:41 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6QGxdsW029201; Sat, 26 Jul 2008 16:59:39 GMT
Date: Sat, 26 Jul 2008 16:59:34 +0000
From: bmanning@vacation.karoshi.com
To: Brian Dickson <briand@ca.afilias.info>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Roy Arends <roy@nominet.org.uk>, namedroppers@ops.ietf.org
Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers?
Message-ID: <20080726165934.GA29158@vacation.karoshi.com.>
References: <48886C4D.4020500@ca.afilias.info> <63C0FFE7-17E6-4ECE-9A12-0537FE2E3F4B@ca.afilias.info> <4888FED2.6060204@NLnetLabs.nl> <E7388E94-D031-4059-91F9-1596A254E21C@ca.afilias.info> <20080725193101.GB8193@outpost.ds9a.nl> <BEADC795-3C76-407A-A979-2B0AAACE0328@ca.afilias.info> <20080725221002.GK29775@commandprompt.com> <OFF4F9438A.D83AC9AB-ON80257491.007DB303-C1257491.007FA301@nominet.org.uk> <20080726144111.GA5204@laperouse.bortzmeyer.org> <488B4F1B.2020104@ca.afilias.info>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <488B4F1B.2020104@ca.afilias.info>
User-Agent: Mutt/1.4.1i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

On Sat, Jul 26, 2008 at 12:21:47PM -0400, Brian Dickson wrote:
> Stephane Bortzmeyer wrote:
> >On Sat, Jul 26, 2008 at 01:14:08AM +0200,
> > Roy Arends <roy@nominet.org.uk> wrote 
> > a message of 28 lines which said:
> >
> >  
> >>When a validator has a trust anchor configured for root, it _expects_ 
> >>signatures for root. 
> >>    
> >
> >Which means there is no way back? If we sign ".fr", and people start
> >to configure the trust anchor for ".fr" in their validating resolvers,
> >we can no longer revert to the original, non-signed, system, should
> >problems occur?
> >
> >Am I correct? AFAIK, DNSSEC has no way to express policies (in a
> >RFC5016-like way) such as "should be signed".
> >  
> 
> You are correct.
> 
> However, if the root was signed, there would be no need for having 
> separate trust anchors configured
> for a signed .fr.

	presuming facts not in evidence.
	how are you to -know- that the root has the "right" DS for .FR?
	most operational keystores will have at least four keys and likely 
	operational practice will be, roughly 3 per relevant org; the current,
	the immediate past, and the next future key.

	as a grad student, I will likely have keys from (at least) these places:

	my school, the parent org (.EDU), the root, the LIR, the RIR.

	that looks like 15 keys... :)

	
> And, this would mean that turning on or off the status of "is .fr 
> signed?" could be handed from the root
> zone, allowing *relative* ease in backing out the signing of any TLD. No 
> configuration changes would
> be needed by the operators of validating resolvers.
> 
> (IMHO, in addition to signing the root zone, there need to be changes to 
> the speed with which changes
> of a technical nature can be made, once the technical administration of 
> a TLD has been authoritatively
> and contractually delegated to an entity. Those include changes to A and 
> AAAA glue records, and
> addition/removal of DNSSEC signatures (and thus the 
> "signed"/"not-signed" status).)
> 
> Brian
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>