Re: [DNSOP] On Powerbind

Mark Andrews <marka@isc.org> Wed, 15 April 2020 00:39 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 5A6083A138A for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 17:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 C0fy0_DXlYh9 for <dnsop@ietfa.amsl.com>; Tue, 14 Apr 2020 17:39:06 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 0E6413A1388 for <dnsop@ietf.org>; Tue, 14 Apr 2020 17:39:06 -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 E25CA3AB002; Wed, 15 Apr 2020 00:39:05 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D3E0E160055; Wed, 15 Apr 2020 00:39:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BA23516005D; Wed, 15 Apr 2020 00:39:05 +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 xMaqOhPzWDQn; Wed, 15 Apr 2020 00:39:05 +0000 (UTC)
Received: from [172.30.42.69] (unknown [49.2.228.79]) by zmx1.isc.org (Postfix) with ESMTPSA id 231AD160055; Wed, 15 Apr 2020 00:39:04 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <4114089.Lb5rXcgMSS@linux-9daj>
Date: Wed, 15 Apr 2020 10:39:01 +1000
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A83CCD84-D2B4-44BE-9A56-E124CB39A5E3@isc.org>
References: <CAHbrMsAbHV8M2GR95nyZ-vCZOGghgxrdVD5NaTC=05q16HBd5Q@mail.gmail.com> <CAHbrMsAg4KMmMzntS-sWSeYJ3CWywC=Jv5pqBFdmCFmsY3tjUw@mail.gmail.com> <alpine.LRH.2.21.2004141951540.5865@bofh.nohats.ca> <4114089.Lb5rXcgMSS@linux-9daj>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/m3DWSu9NwGhv3XxmQocXcl-JI9o>
Subject: Re: [DNSOP] On Powerbind
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 15 Apr 2020 00:39:07 -0000

The DS record doesn’t have a flag field.  If you want to add flags or otherwise
extend DS records it requires new DS algorithms that encode the flags/extensions
inside the digest field.  Its incrementally doable and has implications for all
future DS algorithms.  That said this proposal doesn’t include such a change.

> On 15 Apr 2020, at 10:30, Paul Vixie <paul@redbarn.org> wrote:
> 
> a bit in the parent (DS RRset) to say this delegation point is itself 
> delegation-only would be more interesting. perhaps a way to assure compliance 
> with a contract, thus preventing any ambiguity along the lines of 
> "sitefinder".
> 
> but a bit in the apex (DNSKEY RRset) is still interesting, as a declaration of 
> intent, which is easily monitored to find out if that intent changes, and to 
> allow widespread alarms if that intent isn't lived. one can imagine breakins 
> at the registry or registrar which would have the power to insert new children 
> but not the power to change the apex DNSKEY.
> 
> a mature system would explicitly support this kind of live second-set-of-eyes.
> 
> vixie
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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