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

Mark Andrews <marka@isc.org> Thu, 17 August 2017 03:47 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 C156F132661 for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 20:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 jr8rpiyetwW6 for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 20:47:52 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B47132485 for <dnsop@ietf.org>; Wed, 16 Aug 2017 20:47:52 -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.pao1.isc.org (Postfix) with ESMTPS id D0EC734B6DD; Thu, 17 Aug 2017 03:47:49 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A91D0160052; Thu, 17 Aug 2017 03:47:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8E39D160067; Thu, 17 Aug 2017 03:47:49 +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 Nz4baa-u0QaQ; Thu, 17 Aug 2017 03:47:49 +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 42D07160052; Thu, 17 Aug 2017 03:47:49 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0F82D8298B68; Thu, 17 Aug 2017 13:47:47 +1000 (AEST)
To: John Levine <johnl@taugh.com>
Cc: dnsop@ietf.org
From: Mark Andrews <marka@isc.org>
References: <20170816230917.4475.qmail@ary.lan>
In-reply-to: Your message of "16 Aug 2017 23:09:17 +0000." <20170816230917.4475.qmail@ary.lan>
Date: Thu, 17 Aug 2017 13:47:47 +1000
Message-Id: <20170817034747.0F82D8298B68@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/o_BWyvMr2fGSc4w87TbMKCvTsDI>
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: Thu, 17 Aug 2017 03:47:54 -0000

In message <20170816230917.4475.qmail@ary.lan>, "John Levine" writes:
> In article <20170816071920.BA2C98287EA4@rock.dv.isc.org> you write:
> >> A colleague says "If TLDs allowed UPDATE messages to be processed most
> >> of the issues with DNSSEC would go away. At the moment we have a whole
> >> series of kludges because people are scared of signed update messages."
> 
> Someone is wildly overoptimistic.  
> 
> The problem I run into over and over again is that I run someone's DNS
> and other services, but I am not the registrant and I am not the
> registrar, I just run the DNS.  Either I have to walk the registrant
> through the process of installing DNSSEC keys, or she has to give me
> her registrar account password, neither of which scales.  Slightly
> more automatic processing of updates for which I do not have the
> credentials will not help.

Or you can have credentials to allow the hoster to update the DS
records alone.  UPDATE allows for fine grained credentials.  Named
has had fine grain update support for over a decade now.  You can
specify keys that can do everything and you can specify keys that
can just update a single type.  This isn't hard to do.

The DNS hoster gives the registrant the public key they use to
update DS records.  This is passed to the registrar which uses it
to verify UPDATE requests that change the DS records.  You can do
similar with TSIG but that is a shared secret between three parties.

This is like using master keys and more specific keys.  The only
reason this isn't done today is that we aren't using UPDATE and are
forcing all the transactions through a web interface.

Mark

> R's,
> John
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org