Re: [DNSOP] fragile dnssec, was Fwd: New Version

Mark Andrews <marka@isc.org> Fri, 18 August 2017 01:36 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BC91326E1 for <dnsop@ietfa.amsl.com>; Thu, 17 Aug 2017 18:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4p46Oq1PIQY for <dnsop@ietfa.amsl.com>; Thu, 17 Aug 2017 18:36:09 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1003E132413 for <dnsop@ietf.org>; Thu, 17 Aug 2017 18:36:09 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id F00CB24AE3D; Fri, 18 Aug 2017 01:35:57 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DECF6160042; Fri, 18 Aug 2017 01:36:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C5ED4160070; Fri, 18 Aug 2017 01:36:03 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NFR_hKcq6RyB; Fri, 18 Aug 2017 01:36:03 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 6E923160042; Fri, 18 Aug 2017 01:36:03 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 473E582B17D6; Fri, 18 Aug 2017 11:36:01 +1000 (AEST)
To: John R Levine <johnl@taugh.com>
Cc: dnsop@ietf.org
From: Mark Andrews <marka@isc.org>
References: <20170816230917.4475.qmail@ary.lan> <20170817034747.0F82D8298B68@rock.dv.isc.org> <alpine.OSX.2.21.1708171013140.63290@ary.local> <20170818001153.37E9082B0500@rock.dv.isc.org> <alpine.OSX.2.21.1708172112530.64140@ary.local>
In-reply-to: Your message of "17 Aug 2017 21:13:45 -0400." <alpine.OSX.2.21.1708172112530.64140@ary.local>
Date: Fri, 18 Aug 2017 11:36:01 +1000
Message-Id: <20170818013601.473E582B17D6@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/by8bBwSHO1RMZH7GUFZAOZ1A0oU>
Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Fri, 18 Aug 2017 01:36:11 -0000

In message <alpine.OSX.2.21.1708172112530.64140@ary.local>, "John R Levine" writes:
> On Fri, 18 Aug 2017, Mark Andrews wrote:
> >>> Or you can have credentials to allow the hoster to update the DS
> >>> records alone.
> >>
> >> Of course, but that's independent of how you present the updates to the
> >> registry or registrar.
> >
> > Yet, you chose to attempt to shoot down the proposal based on the
> > premise that you would be giving up full control.
> 
> You appear to be responding to someone else.  My point is that in 
> practice, registries do not provide credentials for DNSSEC updates only, 
> regardless of how they're presented.

And the proposal was for registrars to process them except in the
case where the registry and registrar are the same entity.  The
only thing the registry needs to run is a forwarding agent which
looks at the name of the zone to be updated (sanity checking and
possible database selection for the next step) and the name of the
first record to be updated in the update section to find which
registrar to forward the update to.  This is similar to how nsupdate
works out which zone to update without being told explicitly.

All validation (TSIG/SIG(0)), beyond is the UPDATE in scope, is
done by the registrar which doesn't require the registry to handle
any credentials.

> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org