Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt

"Wessels, Duane" <dwessels@verisign.com> Mon, 20 May 2019 22:35 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 D25BB120074 for <dnsop@ietfa.amsl.com>; Mon, 20 May 2019 15:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 t1l4FOtMHwYl for <dnsop@ietfa.amsl.com>; Mon, 20 May 2019 15:35:56 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.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 43C16120048 for <dnsop@ietf.org>; Mon, 20 May 2019 15:35:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9465; q=dns/txt; s=VRSN; t=1558391756; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=MHVOCsw9xHm1lQKCMf+6KnPgJd/DIn2SQFAKNvaIraQ=; b=oaSGkEV5K07O0YTmoxZxipWFU3i5Hx0YWvgJyUYNB3rrvQHT2KJeBqRp dyQXZMgSk0XkZRh6vSufG2148V3vhGfpufQfr88TZh27hGEViWYAxXFD0 ehvLSj+U4wbzkDLfj+2vj0q8KYJi2wVE9zNro7HkUuibFnI1+tk4kZP+/ eXWenejIUJxfY+TceHbHmv2Ngi/kcWrhkieJIvE5LrL/AnelsgdWGK+xi VpbzR2llb96ZdmSKrAhFY/D5PrEu8mqF1H4D+flEbX3t3M0x/JOXLwhxm w9YYitSpb6h7ok74UjlL8mZ0+cTLfQTafj0IU0uLnxEY9k8ClOYgif+No w==;
X-IronPort-AV: E=Sophos; i="5.60,492,1549929600"; d="p7s'?scan'208"; a="7790645"
IronPort-PHdr: =?us-ascii?q?9a23=3ABdvVqhXbY4iAyRlPXao5qVwI7IXV8LGtZVwlr6?= =?us-ascii?q?E/grcLSJyIuqrYbReAt8tkgFKBZ4jH8fUM07OQ7/m5HzVYsN3Z4DgrS99lb1?= =?us-ascii?q?c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUh?= =?us-ascii?q?rwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrsAndrNQajZdmJ6o+1h?= =?us-ascii?q?fEoWZDdvhLy29vOV+dhQv36N2q/J5k/SRQuvYh+NBFXK7nYak2TqFWASo/PW?= =?us-ascii?q?wt68LlqRfMTQ2U5nsBSWoWiQZHAxLE7B7hQJj8tDbxu/dn1ymbOc32Sq00WS?= =?us-ascii?q?in4qx2RhLklDsLOjgk+2zMlMd+kLxUrw6gpxxnwo7bfoeVNOZlfqjAed8WXH?= =?us-ascii?q?dNUtpNWyBEBI63cokBAPcbPetAr4fzuUYArQewCwevCuPgyD5IiWP50qAh3O?= =?us-ascii?q?QtDQTG0RY8E94SrnjZqsj+OqcIUeCyyanF1TvPYPNI1jfm84jHbBQhoeqUUb?= =?us-ascii?q?ltf8TR1FMgFwXbgVmetIfoOC6a1+oTvGiA9OpvS+avi3U8pgFvvDev3MYsip?= =?us-ascii?q?LIhoIazFDI7zl2wIEwJdChTkNwfN2qEINIui2HK4d6WN4uTmNmtSog17ELuZ?= =?us-ascii?q?C2cDIFxZkj3xLTduCLf5KV7h/hSOqdOyp0iX1mdb6lmhq/8lCsyuPiWcS3zF?= =?us-ascii?q?pHqy9IncPPu30JzBPe78aKRuVg8Uqg3DuAzATe5+BGLE0xm6fWJZwszaM2m5?= =?us-ascii?q?EOq0rMBDX2l1/zjKKOc0Uk/fWn5Pr/b7X9o5+cK5d0igbjMqQygsC/Afo3Mg?= =?us-ascii?q?wJX2WD5OmyyKXt8VD5T7tSgfM5k7XVvI7AKcQFuqG5BBVV0p455xmlEjiqys?= =?us-ascii?q?oYnWMcLFJDYh6Ik4/pO1TWLPD5C/ewnUisnS92y/zaJLHtH5fAI3bZnLv8fb?= =?us-ascii?q?tw5VRQxQU3wNxH4pJbELABIPb9Wk/rs9zYCwc0PBG6wun5E9V9zZ0RWWaUAq?= =?us-ascii?q?KCLqPdr0WI5uM0I+mNa48VvizxJOQi5/7rlXM5g0MSfbG13ZsLb3C1BvFmLF?= =?us-ascii?q?+FYXrwmdoODWAKvgwjTOzslVKCSyNTZ3OoU60g4TE7DZqsDZ3fSYC1nLyBwC?= =?us-ascii?q?C7E4VLaWBAEVCMFm/oep6FW/gSdCKSLNVtkjseVbiuGMcd0kSLvRPmy7d4Zt?= =?us-ascii?q?LT5ysDuI7/nIxw7vHPvRo18yFyA96A1ieGSGQizU0SQDpjlp9yuldwzkzHmY?= =?us-ascii?q?RlivpVX5QH6+xESRw3MYX00eFgCsvzVQSHddCMHgX1Cu66CC08G4pii+QFZF?= =?us-ascii?q?xwTpD71kjO?=
X-IPAS-Result: =?us-ascii?q?A2HCAACyKuNc/zGZrQplGwEBAQEDAQEBBwMBAQGBZYFig?= =?us-ascii?q?kQKmH4lg16WcgkBAQEBAQEBAQEDBAEvAQGEQAKCYDgTAQMBAQEEAQEBAQMBA?= =?us-ascii?q?QECgRGCOikBgmcBAQEBAgFrDgULAgEIDgouAjAlAgQOBQ6DFAGBe6g3hUiEY?= =?us-ascii?q?hCBNIFPihmBQT6BEScME4JMPoJhBIUbgiYEix6PS40vAwYCgg2DE4IYhUSIK?= =?us-ascii?q?IIdik+JM6INAgQCBAUCFYFmgXlwFWUBgkGQUXIBjSWBIQEB?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 20 May 2019 18:35:54 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1713.004; Mon, 20 May 2019 18:35:54 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Matthew Pounsett <matt@conundrum.com>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt
Thread-Index: AQHVD1xixd//FcXdcUKOJeLd2Piadg==
Date: Mon, 20 May 2019 22:35:54 +0000
Message-ID: <AA5F8AB2-EFC7-4A11-8999-F775C34C09E1@verisign.com>
References: <155009468256.9559.12509906855495134896@ietfa.amsl.com> <923006F8-EB5A-4098-81A2-782BC90BF220@verisign.com> <CAAiTEH_GmvNVgAZzwG+oaQrtNd_b=kpDSRz7ErbmTjuXrzziWg@mail.gmail.com>
In-Reply-To: <CAAiTEH_GmvNVgAZzwG+oaQrtNd_b=kpDSRz7ErbmTjuXrzziWg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_BA8906D6-5186-44CD-BF58-105A2EDEB756"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4hlWv5dzlkYpHJdcy9YbULzhj2U>
Subject: Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.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: Mon, 20 May 2019 22:35:58 -0000


> On Mar 25, 2019, at 6:53 AM, Matthew Pounsett <matt@conundrum.com>; wrote:
> 
> 
> 
> On Wed, 13 Feb 2019 at 22:56, Wessels, Duane <dwessels=40verisign.com@dmarc.ietf.org>; wrote:
> The only change to this document since -05 is to note that ZONEMD has been allocated RR type code 63 by IANA following an expert review back in December.
> 
> I haven't reviewed this for a couple of revisions, so some notes here that don't apply to the new codepoint. :) . I've tried doing some searches of the discussion history to make sure I'm not raising points already addressed, but my apologies if I've missed something.
> 
> Section 2 discussion:  I was initially ambivalent about whether multiple ZONEMD records should be allowed with different digest types.  Having gone back and re-read some of the discussion, I'm persuaded that it would be beneficial to allow multiple digest types to be used on the same zone instance.  I think we'd want to have a bunch of discussion about the details in order to keep code complexity under control, though.

Thanks Matt, this seems to be the consensus, so we'll be adding some text about how to interpret multiple ZONEMDs.


> 
> Section 3.2. discussion:  Unless there's a potential benefit to non-apex ZONEMD records that I'm not seeing, I think it makes sense to forbid them.  Was there a particular thing that could be enabled by that, which prompted the suggestion?

I'm not aware of any use for non-apex ZONEMDs.  I think it comes down to the choice to either be liberal or strict in what you accept.


> 
> In 3.4.1 would it make sense to include a sentence explaining the catch-22 that would result if the RRSIG covering the ZONEMD record were included in the digest?

Added, thanks.


> 
> In section 4, I suggest replacing all of the instances of "provably [un]signed" with "provably [in]secure".

Good catch, thanks.


> Section 5 discussion: I can't remember if I commented on this bit before or not, but just in case.. I support keeping the reserved field.  It seems to me that if we have to get a new type for an incremental-friendly version of ZONEMD that we're going to have implementation fragmentation and a migration issue.  Especially if we don't allow multiple ZONEMD records, I can imagine it being difficult to have both in the zone at once, and that it could be hard to specify what should happen if an operator wants to migrate from ZONEMD v1 to ZONEMD v2 without knowing which one the consumers of their zone support

Appreciate the feedback.

DW