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

"Wessels, Duane" <dwessels@verisign.com> Tue, 11 May 2021 16:16 UTC

Return-Path: <dwessels@verisign.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 3E8863A1D11 for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 09:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_MED=-2.3, 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 (2048-bit key) header.d=verisign.com
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 Mji73waHT9BR for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 09:16:15 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 1EDAC3A1D10 for <dnsop@ietf.org>; Tue, 11 May 2021 09:16:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=7749; q=dns/txt; s=VRSN; t=1620749775; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=j36ipqgMjt5GQvQElGagAq/p0XIynDaxOoowoICDVNE=; b=Gl6jpthN7dy3CrcqDJkOuVe2DVKEWE++THG+nNnSeicgLAQa5FwD+Fen oAR+o2ffnw+vaIIQL1Ty8SfV0SISGkF7YT3jrbYK8oPhXOhoHUiS3gwdk nmKY5H2C+pe8JEW/p+cu1U5It6YfTvv4j/qcnN2h03V2NLNHtNhK6TffP rti0PJkxW/gZjaadGNq/hEweS5qinNbQ7Q0sX+smzXCYBfYGeHoSvIcWI SZOVaL06ei7sZl2HED6kP8sWCSffzj0hGxlQZizh1pV0Myb1wvUs0kF3l oRk1DqUoQ2FVQITgs+eFmrY+OeCaYksdaBTUUJHq4tGP8khmJCvn2MWB6 A==;
IronPort-SDR: QPlbHccfN6qjqLWiog0kJt+h7KUgy2qaKe9GI5Wimiplf6zkDltE7eaoHvk8zLOm9DRP0uyjEh /z9gOWpMWUObLzSbpjJdRL/QBt3mUZoayGuyLd3Eofu6t4LZ96ZfpXsYBkIwQ5z1KtuOTJ9XNx EHclU4Rhqv7n06MFJY08zjB2gQAI4kk2yfO9XYgROimzZjHTIWC8r1nye7oR50pS3hrZizFusP v3c3WOdoAOcJeXXJ3fz3BrAlGf31p6gQWl0cscyL8/P1utNOoaB4YVStXrPQ+wm9C5cnkhBuCA wSc=
IronPort-HdrOrdr: A9a23:hGU1eKiS0UNgG4vQ19rKvbNDxHBQXgcji2hC6mlwRA09TyX+rb HKoB17726XtN9/YhEdcLy7VpVoIkmyyXcd2+B4AV7IZniEhILHFuBfxLqn7THmFzb36+JRkY xxGpITNPTASXx3l9zz7gX9MdoxqePszImYwcPT1W1kQw0vUbxn9AsRMGumO1d7XxZLHqA0E5 eg5s5KzgDKRUgq
X-IronPort-AV: E=Sophos; i="5.82,291,1613451600"; d="p7s'?scan'208"; a="6991480"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Tue, 11 May 2021 12:16:12 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2242.008; Tue, 11 May 2021 12:16:12 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Mark Andrews <marka@isc.org>
CC: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] ZONEMD was Re: [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Thread-Index: AQHXRf73ZpOnFd47YU6vZb/76jqKPKreuPsA
Date: Tue, 11 May 2021 16:16:12 +0000
Message-ID: <56AC3A3D-8FF5-4FBD-9E7B-5C9D06087160@verisign.com>
References: <F4CE48A1-7AB0-45D0-97FF-158CE3A04EE1@icann.org> <3EE971EE-0777-44D6-9CD2-771B92FFE938@hopcount.ca> <1d822219-8ab9-2cb7-d0a4-9b8afc39058d@powerdns.com> <2952D408-117B-40D0-B859-7A8E4111629E@hopcount.ca> <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com> <25971B7D-718C-42E3-8F04-2D235776C66B@icann.org> <4312DB4B-A9E0-48E8-BD79-7358080065F4@isc.org> <554EF35D-E06B-4F7B-9DDA-90DA8470F6F3@icann.org> <EC0B2E2A-308F-4232-85B9-60289437E52C@isc.org>
In-Reply-To: <EC0B2E2A-308F-4232-85B9-60289437E52C@isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.6)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_D4EE3CDE-D3AA-411A-BCAD-EB35DFB6AD20"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-oRdokZApFueNvcNqkd9epG2tnU>
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 16:16:20 -0000


> 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