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

Eric Rescorla <ekr@networkresonance.com> Thu, 14 August 2008 01:23 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 EDDAE3A6A70; Wed, 13 Aug 2008 18:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.246
X-Spam-Level:
X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 xnjq6RS0UNDF; Wed, 13 Aug 2008 18:23:12 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C3D63A694C; Wed, 13 Aug 2008 18:23:12 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KTRS4-000EpE-6n for namedroppers-data@psg.com; Thu, 14 Aug 2008 01:16:32 +0000
Received: from [74.95.2.169] (helo=kilo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <ekr@networkresonance.com>) id 1KTRS0-000Eoe-JQ for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 01:16:30 +0000
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 2DAE05369E9; Wed, 13 Aug 2008 18:16:26 -0700 (PDT)
Date: Wed, 13 Aug 2008 18:16:25 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Mark Andrews <Mark_Andrews@isc.org>
Cc: Eric Rescorla <ekr@networkresonance.com>, Joe Abley <jabley@ca.afilias.info>, Ray.Bellis@nominet.org.uk, Namedroppers WG <namedroppers@ops.ietf.org>
Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers?
In-Reply-To: <200808140043.m7E0hkbK096439@drugs.dv.isc.org>
References: <20080813171816.D7B3C50846@romeo.rtfm.com> <200808140043.m7E0hkbK096439@drugs.dv.isc.org>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20080814011626.2DAE05369E9@kilo.rtfm.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

At Thu, 14 Aug 2008 10:43:46 +1000,
Mark Andrews wrote:
> 
> 
> > The problem here is not PKI or DNSSEC but that we have no good
> > mechanisms in the generic case for determining whether a given
> > individual is authorized to control a given domain. This makes any
> > cryptographic authentication of domain name ownership problematic.
> 
> 	Most zones are created when they are bought.  The buyer
> 	specifies the NS, DS and glue records as part of that
> 	transaction.  The credentials for future transactions are
> 	established as part of that initial transaction.
> 
> 	Now when zones are sold there are issues but those issues
> 	exist independent of whether DNSSEC is in use or not.
> 
> 	If you are authorised to update the delegation information
> 	in the parent then you should be authorised to change the
> 	DS records in the parent as they are just part of the
> 	delegation.  Changes to NS, A, AAAA and DS records as part
> 	of the delegation are equally dangerous as each other.
> 
> 	There is no need to make the parent / child trust relationship
> 	more complicated with DNSSEC than it is without DNSSEC.

Yes, I agree with that. But in many of these cases, the credentials
are "here's the email address to contact the technical contact with".
This is of course just as problematic as e-mail answerback for 
certificate authorites. 

And to the extent to which the registrars/registries have a
DNS-independent way of validating the domain owners, the CAs 
(who in at least some cases are the same people!) could
presumably leverage that to determine whether to issue
the certs.

-Ekr


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