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

"John R Levine" <johnl@taugh.com> Fri, 18 August 2017 02:39 UTC

Return-Path: <johnl@taugh.com>
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 EB49D1326E1 for <dnsop@ietfa.amsl.com>; Thu, 17 Aug 2017 19:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=pF6dctGO; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=St3yQMT2
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 Zfq9HB1CFmff for <dnsop@ietfa.amsl.com>; Thu, 17 Aug 2017 19:39:34 -0700 (PDT)
Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB13613226B for <dnsop@ietf.org>; Thu, 17 Aug 2017 19:39:33 -0700 (PDT)
Received: (qmail 16680 invoked from network); 18 Aug 2017 02:39:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4126.59965364.k1707; bh=TVE5JcusYEMswIo+QfBegLNXXDBGfXMSTcNX70C1oUY=; b=pF6dctGOsTDc0hsLYFGrmpHr8m4uL/baHSXi3IbcG0zKa4EB7cc1Ld7G0NpbNkZeoHLz8UD/eFeEW3aExEHQcOr5zas1LpVg+H3lRgwPptAMN1GXhbz4y8nV98qWTwmBbFGkXtyM+CwwGHQzLNaf/cJ8vU81Ljnd3NmYM5oqlpPWWGsBsQxTCud5XHlOAthy3gNiVEGi8dWjaTCjBAIj4wSJZ8IyEaNj3XF/qNaQ+mV7Wo75Jv5w90fTq3/wksr/
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4126.59965364.k1707; bh=TVE5JcusYEMswIo+QfBegLNXXDBGfXMSTcNX70C1oUY=; b=St3yQMT2E8KvVR53Ugu1cfiTg0ObfWIBj9hhEYc4diM8dEOqEH65e4lqEzHWIPOxYbvDvBXRAjuS67c0fVSdQycZIOWzPfDDJrn9hyOFyJGQHPssfdTuew85bjTHt1tnAOhvlz/kxiMEx+Jkwyazu8D1RGtXl71B64fYHls1KcRz9yYgGHR8ih75RxIfDdTBw6XRhISatDFFNvpF5bGiaPTCiJwIA1C/38ys2+tafk3v6C9KCG4JU+zDKMfwr87q
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 18 Aug 2017 02:39:32 -0000
Date: Thu, 17 Aug 2017 22:39:31 -0400
Message-ID: <alpine.OSX.2.21.1708172230120.64415@ary.local>
From: John R Levine <johnl@taugh.com>
To: Mark Andrews <marka@isc.org>
Cc: dnsop@ietf.org
In-Reply-To: <20170818013601.473E582B17D6@rock.dv.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> <20170818013601.473E582B17D6@rock.dv.isc.org>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XjdgNdigDEzgtlnhXDDSYwmwg60>
Subject: Re: [DNSOP] updating 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 02:39:36 -0000

On Fri, 18 Aug 2017, Mark Andrews wrote:
> 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.

I'm sorry, but once again I can't see how response is related to what 
you're responding to.

It is a business issue whether the DNSSEC records (and the NS for that 
matter) are updated through the registry or the registrar.  Some do it one 
way, some do it the other, and the registars and registries I've talked to 
feel very strongly about whichever way they do it.  Either way, the 
problem is that almost none of them issue credentials that let you update 
a zone's DNSSEC separate from letting you update everything else about a 
registrant.

As I've said a couple of times, where you present those non-existent 
credentials and whether you do it through TSIG or some web thing (web 
servers are really good at 3xx redirects) is an implementation nit.  At 
this point Jacques' proposal that gives you a challenge token to stick in 
your zone to prove you're authorized is looking pretty good.

R's,
John