Re: [DNSOP] ZONEMD was Re: [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Mark Andrews <marka@isc.org> Tue, 11 May 2021 19:49 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 084853A241A for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 12:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=So9ra+HI; dkim=pass (1024-bit key) header.d=isc.org header.b=RIJKALOx
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 aWZMqPVWs4An for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 12:49:17 -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 EDB5E3A2422 for <dnsop@ietf.org>; Tue, 11 May 2021 12:49:16 -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)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 749453AB032; Tue, 11 May 2021 19:49:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1620762555; bh=aVBdP4XkHI6kqUcVQ1mXHk5mnX5/ye+yc3rGNzkV8tg=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=So9ra+HIXuW0I9ogYf8lNZWeExtIo5BDNM+gUqRwaxWTNoXmKS6DQmi3FmFCTqUEn wbW54xkRW5Wo2LcFKPWgRPB/xfHTR5zuxBdNHc3Mo1DV3FqXlP3QINC5Zff3j8CqW9 Jwx7OXy9rscpv1pqacNbjAe4TTtxNHw6kPRaAhp4=
Received: from zmx1.isc.org (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3EC1916009C; Tue, 11 May 2021 19:49:15 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F17C016009A; Tue, 11 May 2021 19:49:14 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org F17C016009A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1620762555; bh=hsejem8UEIsgx0dpoNVjnfQ64c7cLf4QzMjpYq5LhSE=; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject: Date:Message-Id:To; b=RIJKALOxrYlN3V5PhryUoaKClaKyezi++FNP88i2LQlcD5vQht9NT6uER8XsrJL0e ekoKHKBjTWR5IcV/6GLYIteSO9XGajG/T3++2p1Q/JEkLymg6rZ034gW2kO9z0rekG uZLI9Qb+6SpVo4fRRjjuZ9y+6NDIb1FfanJIdCJw=
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 e0Gx7A6eD3ag; Tue, 11 May 2021 19:49:14 +0000 (UTC)
Received: from [172.30.42.83] (n49-177-132-25.bla3.nsw.optusnet.com.au [49.177.132.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 51DFF160053; Tue, 11 May 2021 19:49:14 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Mark Andrews <marka@isc.org>
Mime-Version: 1.0 (1.0)
Date: Wed, 12 May 2021 05:49:11 +1000
Message-Id: <CA3BFCBC-0827-4874-85A1-12308C2F35C3@isc.org>
References: <56AC3A3D-8FF5-4FBD-9E7B-5C9D06087160@verisign.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>
In-Reply-To: <56AC3A3D-8FF5-4FBD-9E7B-5C9D06087160@verisign.com>
To: "Wessels, Duane" <dwessels@verisign.com>
X-Mailer: iPhone Mail (18D70)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Mm8kAzzVGo4-YY9D76PvQrbd__o>
Subject: Re: [DNSOP] ZONEMD was Re: [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
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: Tue, 11 May 2021 19:49:21 -0000

While it is not written down that it is frozen you are required to give enough information to implement it with the expectation that it will be implemented by multiple vendors. 

Once implemented you then have to deal with backwards compatibility with existing implementations if changes are made.

Mixing I-D/RFC and template mechanisms for assigning and publishing type points is fraught with danger as you then run into issues we have been seeing here.  You actually thought about making ZONEMD future proof which was good and should have provided enough flexibility.  
-- 
Mark Andrews

> On 12 May 2021, at 02:16, Wessels, Duane <dwessels@verisign.com> wrote:
> 
> 
> 
>>> On May 10, 2021, at 5:44 PM, Mark Andrews <marka@isc.org> wrote:
>>> 
>>> 
>>>> On 11 May 2021, at 09:20, Paul Hoffman <paul.hoffman@icann.org> wrote:
>>> 
>>> On May 10, 2021, at 4:14 PM, Mark Andrews <marka@isc.org> wrote:
>>>> Actually, the process problem is that record format keeps changing AFTER the code point has been assigned and the record format THEORETICALLY been FIXED.
>>> 
>>> Mark makes an excellent point, one that people in the DNS world routinely forget.
>> 
>> Just for reference ZONEMD switched two fields between draft-wessels-dns-zone-digest-05.txt and
>> RFC 8976.  "Digest Type | Reserved” -> "Scheme | Hash Algorithm”.  This resulted in BIND rejecting
>> zones with ZONEMD records using SHA-512 digests (digest field has the wrong length for Digest Type 1).
>> Renaming fields is fine.  Reordering/repurposing non reserved isn’t as it breaks stuff.  Now we are
>> making BIND compatible with RFC 8976 but we should never have been put in this position.
> 
> Mark,
> 
> Thank you for quickly making this change in BIND.  You are correct that
> the case of ZONEMD the interpretation of fields did change, although the
> wire format did not.
> 
> You've made the point a few times that code point allocation freezes the
> record format (not just in wire format but also presentation and meaning).
> When I went through the RR type allocation process this was not evident
> to me.  Is this (theoretical?) "policy" written down somewhere?  RFC 6895
> doesn't seem to say anything like that.
> 
> DW
> 
> 
>