Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

"Wessels, Duane" <dwessels@verisign.com> Thu, 15 October 2020 17:02 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 855A73A0A0B; Thu, 15 Oct 2020 10:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 HaEzez1K27Cp; Thu, 15 Oct 2020 10:02:19 -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 9A3643A00C4; Thu, 15 Oct 2020 10:02:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=10184; q=dns/txt; s=VRSN; t=1602781340; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=8dT/QNpv2xi4ncJtIe96pzMl9B7KOxyBXCYGopOOAAI=; b=G8N6GWdmxlFySAC4K9axuubR4L8sTw1nhRmat6ZfO892NRK8JziZUgSC //GzBkBcM+kmd7/a0xr5htP+Xsi1+bSlbwH7hr9oUW3qcqTUoJGKADoLV iZmnn0Bx63UiX4W58P+j4LdQUEJKiBb6RADPO4u5dk1Gr8jEOQRCA8TDc PkByHEW8r1s7b48rIpHJdmOrVT6BPB4dluXrDqY2ERLyVrOsIRs4DENLW /Wm4KtskRJiSu+sXHYVOaNK2nZdzBHZrvcSYnZTNl6b7JDIyyGplarCrZ wiDNVOVIbfLJRE9UrXw1hwo3tD/yijqo7vMQ9u3uoC1ygBMS+dV0sczgQ g==;
IronPort-SDR: KKt+8n+G3p/9eQztXAalqGeY8VDBdKqPwMDVwop3YgwzQfa8SJ4hD5lnotAph67d5HaN5oZOVa qcHDEUr6R49tCB08yoMwXq6cHTwZ+/piZCL8+I8xdPA2TOsmBoB/N53aYLtKh9Tv1Aid1eW0MA B3WLXWiNJDlnNRRPx9dM4h66k1tX3myouxyImm7sb2ZJcDax7yN6vjHpr+U01ruqVvVe8ZRjlR xnvXk4NVLW+a7sdOwyPIaXzuAgQvc3iWxsanTIq8COfRdr8k5Lp/SueSHH6DMIY6hODQs3NVbx 68E=
X-IronPort-AV: E=Sophos; i="5.77,379,1596513600"; d="p7s'?scan'208"; a="3194731"
IronPort-PHdr: =?us-ascii?q?9a23=3AtutCjxwP3t0DV87XCy+O+j09IxM/srCxBDY+r6?= =?us-ascii?q?Qd0ugSI/ad9pjvdHbS+e9qxAeQG9mCtLQa0KGK6ejJYi8p2d65qncMcZhBBV?= =?us-ascii?q?cuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx?= =?us-ascii?q?7xKRR6JvjvGo7Vks+7y/2+94fcbglVhjexe7J/IRu5oQjeqMUdnJdvJLs2xh?= =?us-ascii?q?bVuHVDZv5YxXlvJVKdnhb84tm/8Zt++ClOuPwv6tBNX7zic6s3UbJXAjImM3?= =?us-ascii?q?so5MLwrhnMURGP5noHXWoIlBdDHhXI4wv7Xpf1tSv6q/Z91SyHNsD4Ubw4RT?= =?us-ascii?q?Kv5LpwRRT2lCkIKSI28GDPisxxkq1bpg6hpwdiyILQeY2ZKeZycr/Ycd4cWG?= =?us-ascii?q?FPXNteVzZZD428cYUBEvYBM+hboYnzpVQAqhq+ChWjC+70xT9Emnr20Lc60+?= =?us-ascii?q?g9Dw3L2hErEdIUsHTTqdX4LKkeXuCrw6nT1jXMcfdW2Szl5IPVfB4hvOuDXb?= =?us-ascii?q?Rufsbf1EIiEB7Kj1uOpoz+JDOayOANs3OA4up+S+2vkW8nqxpwojigwMcgkJ?= =?us-ascii?q?XGhoUQyl3d8yhy3Yk6K8GiRkFhfd6kDIVftzucN4ZuTM4vXWFltiYkx7AFpZ?= =?us-ascii?q?O2cisHxYknyhDfdfGJfYaG7BLiWeqPLjl1mm9pdr2xiRqv7USuxfHxW9So3V?= =?us-ascii?q?tIriRIlt/BvW0O2RzL8sWLV+dx8l281TuN2Q3f8PxILEA6mKbBJJMswaY8mo?= =?us-ascii?q?cPvUjZAyP7mln6gLWLekgr+eWk8fnrb7bgq5SBLYF7kBv+Pb4rmsGnBOQ4NR?= =?us-ascii?q?UBUHaD9OSn0b3j4VX5QLJXjv0qiqXZsI7VJcAcpqOhHgJbzp4t5wu/ADm+39?= =?us-ascii?q?oXnGULIE9fdBKZk4fpPEvOIOjiAfilnlugiilrx+rdPr3nGJnCMn/DkLL5cb?= =?us-ascii?q?Z87U5T1hYzwMhC655IEL0NPfD+V0HruNDFDhI0PRa4zunkBdll04MRQ2OPAq?= =?us-ascii?q?uXMKPItl+I4/oiLPSCZYALozb9MOYq5/r1jXIih18SY7Op3ZoMaHC5EfRmJV?= =?us-ascii?q?+VbmbrgtcECWsKpBYxTPT2iF2eVj5ef3eyULwn5jE0E4+mDJnMRpyjgLCb2y?= =?us-ascii?q?e7BJJWbHhcCl+QCXfoa5mEW/AUZS2PLM5ujCcEVaO/RI8lzhGjrAD3x6Z5Lu?= =?us-ascii?q?XK4C0YtInj1Nl65+3Vjx096Tt0D8GG3m6QSmF7hHkISCMs0KB+v0N91lmD3b?= =?us-ascii?q?J/g/xCGtxZ/+lJXRsiNZ7A0+x6DMj/VR/bftiTRlamXsyqATAvQdItzd8Cel?= =?us-ascii?q?tyG9O5jhDExyqmGqIal7qQBJAt86Pc2H7xKNhkx3nb1akhgEcpQtBTNWC9h6?= =?us-ascii?q?5w6RTTB4DTn0WejaaqerwW3DTR+2eb0WqOoEZYXRZsUaXHU3ETfErWosrl5k?= =?us-ascii?q?PMVLKuBrEnPRFAyc6GMKdFdtrpjVBeTvf5JNvee36xm3u3BRuQ27yMapHqe2?= =?us-ascii?q?IF3CjGCUgLjRwT/XicOQg5HCehrHrUDCZyGlL3f0Ps7e5+pWumQU8y1AGKaF?= =?us-ascii?q?Vh26Op9R4Vn/OcSukT3qkftScgtTp0AFi908jRC9qaqAoyNJlbNO897R9m+F?= =?us-ascii?q?n2/1h8M4evB6FvmlBYdB546RDAzRJyX89/nNMxoXcxiEJeNKue3RkJIz+H0I?= =?us-ascii?q?vrN7nMAnf/5hG0aqHQnFrZ1YDFqe809P0kpgC770mSHU04/iAiioEN3g=3D?= =?us-ascii?q?=3D?=
X-IPAS-Result: =?us-ascii?q?A2HBAABDf4hf/zCZrQpgGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBT4NGgQgKlUyDeoYXkCyBaQQHAQEBAQEBAQEBBAQBLwQBAYRKAoIKJ?= =?us-ascii?q?jgTAgMBAQsBAQEFAQEBAQEGAwEBAQKGUYI3KQGDagEBAQECAXkFBwQCAQgRB?= =?us-ascii?q?AEBAS4CHxEdCAIEDgUOgxgBgksDDhGsLHSBNIgfDYIUEIE4gVOLfoFCPoERJ?= =?us-ascii?q?xyCTT6CGkIEgSM5g0uCLQSTDqQWVAMHgmqETYJfjjeFDh+hSqELjm6DYAIEA?= =?us-ascii?q?gQFAhWBa4F7cBVlAYI+PhIXAg2OKhgUjhB0AjYCBgoBAQMJjTeBEQEB?=
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.2106.2; Thu, 15 Oct 2020 13:02:16 -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.2106.002; Thu, 15 Oct 2020 13:02:16 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: The IESG <iesg@ietf.org>
CC: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>, "draft-ietf-dnsop-dns-zone-digest@ietf.org" <draft-ietf-dnsop-dns-zone-digest@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>
Thread-Topic: [EXTERNAL] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Thread-Index: AQHWot9ksyjReKGrmE2zePWm+bTfqqmZJy0A
Date: Thu, 15 Oct 2020 17:02:16 +0000
Message-ID: <D4ADDDAD-295F-46F6-8EA8-A4DA06EECD5C@verisign.com>
References: <160215590178.19643.8185294724542473578@ietfa.amsl.com> <514C5EA8-2814-42AA-9787-455445BA828D@verisign.com> <MN2PR11MB43665A8B2DE4ECFF99CEAB7EB5070@MN2PR11MB4366.namprd11.prod.outlook.com> <1C5BF513-7FDD-404E-AC0E-09C0379864E7@verisign.com> <MN2PR11MB4366618DA4A0BBE5DADBE765B5020@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4366618DA4A0BBE5DADBE765B5020@MN2PR11MB4366.namprd11.prod.outlook.com>
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.4)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_669D439F-8CA9-4126-943C-83960DDD5B1D"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5TAHhosJvxFm_7AVvwSmLkRuw2M>
Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
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: Thu, 15 Oct 2020 17:02:21 -0000

Dear IESG,

I believe all outstanding comments and concerns have now been addressed, so revision -14 has been posted.  

DW



> On Oct 15, 2020, at 3:38 AM, Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
> 
> Hi Duane,
> 
> That looks good.  Thanks for accommodating.
> 
> Regards,
> Rob
> 
>> -----Original Message-----
>> From: iesg <iesg-bounces@ietf.org> On Behalf Of Wessels, Duane
>> Sent: 14 October 2020 13:35
>> To: Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org>
>> Cc: draft-ietf-dnsop-dns-zone-digest@ietf.org; Tim Wicinski
>> <tjw.ietf@gmail.com>om>; dnsop@ietf.org; dnsop-chairs@ietf.org; The IESG
>> <iesg@ietf.org>
>> Subject: Re: Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-
>> digest-12: (with COMMENT)
>> 
>> 
>> 
>>> On Oct 12, 2020, at 8:56 AM, Rob Wilton (rwilton)
>> <rwilton=40cisco.com@dmarc.ietf.org> wrote:
>>> 
>>> 
>>> 
>>>> 
>>>>> 
>>>>>  2.  The ZONEMD Resource Record
>>>>> 
>>>>>     It is
>>>>>     RECOMMENDED that a zone include only one ZONEMD RR, unless the
>>>> zone
>>>>>     publisher is in the process of transitioning to a new Scheme or
>>>> Hash
>>>>>     Algorithm.
>>>>> 
>>>>> I'm not quite sure how well this fits with sections 2.2.3 restriction
>>>> that
>>>>> SHA384 MUST be implemented, and SHA512 SHOULD be implemented.   As a
>>>> recipient
>>>>> of the zone info I understand that I would need to implement both, but
>>>> as a
>>>>> sender am I allowed to only send SHA512, or both, or must I always
>> send
>>>> SHA384?
>>>> 
>>>> As sender (publisher) you are allowed to publish whatever you want.
>>> [RW]
>>> 
>>> Okay, taken in conjunction with 2.2.3 that didn't seem clear to me.  My
>> reading is that the sender SHOULD only send one, and [everyone] MUST
>> support SHA384, effectively implying that is SHA384 that MUST be sent ...
>> Perhaps the RFC 2119 language in section 2.2.3 needs to be restricted to
>> receivers processing ZONEMD records?  ... or some other way to convey the
>> difference in requirements on algorithm implementation between senders and
>> receivers.
>>> 
>> 
>> 
>> Hi Rob,
>> 
>> To address this, here is what we suggest:
>> 
>> In sections 2.2.2 and 2.2.3, rather than saying "MUST/SHOULD be
>> implemented" we'll say "MUST/SHOULD be supported by implementations."
>> 
>> The paragraph about multiple digests at the start of section 2 will be
>> moved to this new section 2.5:
>> 
>> 2.5.  Including ZONEMD RRs in a Zone
>> 
>>   The zone operator chooses an appropriate hash algorithm and scheme,
>>   and includes the calculated zone digest in the apex ZONEMD RRset.
>>   The zone operator MAY choose any of the defined hash algorithms and
>>   schemes, including the private use code points.
>> 
>>   The ZONEMD RRSet MAY contain multiple records to support algorithm
>>   agility [RFC7696].  [RFC Editor: change that to BCP 201] When
>>   multiple ZONEMD RRs are present, each MUST specify a unique Scheme
>>   and Hash Algorithm tuple.  It is RECOMMENDED that a zone include only
>>   one ZONEMD RR, unless the zone operator is in the process of
>>   transitioning to a new scheme or hash algorithm.
>> 
>> 
>> DW
>> 
>> 
>