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

"Wessels, Duane" <dwessels@verisign.com> Wed, 14 October 2020 12: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 91FBF3A09D1; Wed, 14 Oct 2020 05:35:07 -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=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 6iRKyF0Spg1J; Wed, 14 Oct 2020 05:35:03 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 DF7CD3A09BA; Wed, 14 Oct 2020 05:35:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9186; q=dns/txt; s=VRSN; t=1602678904; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=lGj4r613jbV7yVDh4mkl5mBq/3YYI0mjx6DPozdrwxg=; b=LUjwX0j3TFZCSmwmEyGFykLNglPmvbm1c0VySbS/J6lYKo3S2mDQ0qqw 3OV46JM4ndrNp/OfO7x4OgJKwgv3TxqGvBAcU1PhNbNdlSBEbrxeVYQCP FH4bLhKaD2KOHbHOwySGMMXVUUZaUhwtIHdcG+sDO9dy9WxzWFdMIV9NT GXOdpsP9OKjAQi2Pb5fEArGg5FfgTlT3Kfv6rijraS3K5ngFII54Rf0V5 hpgOpu1wFngSff8Y1YPt9apsjsTaAUvdxWPRdVSs8ddvgShSOWorZqaZw sKsh2htkGkzxUL1oUp9/2lVe8WReQRJM0u/+GTnz9dbvzlFHoS7Wxxt7y A==;
IronPort-SDR: gc4d91qV3DwDVUx6z3HINLWEjNT9ePwb6E3+U/PZ/tJz5/kpztNUDgOhkko6SJHVTwVRm2Sflu 3aGfGJhLFUJhQOFzgZmZO2sXW7EA/SAwofWRJCrw5Gnj0qOB0isp4us0lseaeka89ak6l/XRKT JjSoEEonMm3OMkn3QfcSRr0asUN3RsHmWFIHoxKU0LyTXLRUBUcBLZSJr3Bbsqs/cuir7uJaeB fKzav8jzF8XWxOuiaZmqrPnLWQPaGjq036xAWdRZ768vYXcCLb9dYHYvUIkDhlrXV7esxm9gT9 9uk=
X-IronPort-AV: E=Sophos; i="5.77,374,1596499200"; d="p7s'?scan'208"; a="3368449"
IronPort-PHdr: 9a23:tUEFchHXdeJT3igNVxjlv51GYnF86YWxBRYc798ds5kLTJ76pcu8bnLW6fgltlLVR4KTs6sC17OJ9f65EjVeqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjWwba5wIRmsrAjdq8YajZZjJ60s1hbHv3xEdvhMy2h1P1yThRH85smx/J5n7Stdvu8q+tBDX6vnYak2VKRUAzs6PW874s3rrgTDQhCU5nQASGUWkwFHDBbD4RrnQ5r+qCr6tu562CmHIc37SK0/VDq+46t3ThLjlTwKPCAl/m7JlsNwjbpboBO/qBx5347Ue5yeOP5ncq/AYd8WWW9NU8BMXCJDH4y8dZMCAeofM+hFs4nzqVgArRW8CgerBePg1jBHi2T53aEm1uQsCwHG0BA+E98IrX/arM/1NKAXUe2twqXHzSvMb+hN2Tjj7IjIaQgtquyCU7Jta8XRz1cgGw3YhViXtIPkMS2a1v8Ws2eF6+pgTvmii3A5pAFroziv3cYsiobPho4P1l/E8iB5zZ8zKNalR0F1fcSqH4FMtyGGKYR2WMUiTnlmtSskyrAIuYC2cSsWxZkpxBPSdvyKfYiW7xztWuifITZ1iGxqdr+hmhq8/kauxvDgWse7zFtHszZIn9vMuH0J0RHY98uJSuNl80u8xTqDzR3f5+NKLEwuiKbWK5AszqQ/m5cXqUjPAzP6lF/rgKKUakko4PWk5uvkb7n8u5ORNIl5gRzkPKs0gMywG+E4PxALX2ic5OuzyqXu/Vb8QLVWlv02lbTZsIzCKcQbuKG5BwhV354+5hijFzmqzdQXk2EIIl1EZB6LkZLlO0/SL/D/F/e/m06gny12yPzcIL3hGI7NLn7ZnLj9erZ97lZQyAs1zd9B+5JZEqwNLO7pVkPsttHVAAU1PxG0zuvpEtlw2YcTVXqKAqCDMaPStVGI5vgoI+mJfIIapTj8JOY+5/71k3A5nUQdcLK33ZQJcnC4H+9mI0SWYXrqmNsODWAKvg8mQOzwlFKCSSJTZ2q1X68k/DE6BoOmDYPfRoCqhryMxCi2EoFKaWBHEVCDDXDoe5+YVPcLbSKfOdJukjkeWri7V4AtzxCuuxHmy7ppNObU/TcYtZ373thv++LTjQ0y9SBzD8mFzm6NVXt7nm0URzMv3aBwv1B9ylma3adlhfxYDttT5+tQXggnM57c1PV2CtH1WgLHYNiFUUupQtSpAT4vVdIx38QDY0djFNW+gBDPxS2qA6Ual7aTHpw77rrc32TtJ8Z603vGyKshjlc8TstOK2KmmqB/+hPcB47MiUqZlqKqeb4A0y7K8WeJ1XCOs11AUA5sTaXFWmgSaVbQrdTi4UPCV6SjCbU5PQtdx86OMKxKasfmjV9eXvfsJMzeY36tm2e3HRuH27WMbJHte2UFxSnSFEgEnBoS/XacLggzHSahrHzCDDxgD17vZFns8eZmonOhUkA01x2Kb1Fm17et+x4am+ecS/wI07IFpightzt0EEy639LMBNrT7zZmKe9mZtl131ZDyWXf/0xnIZ2kM6dkxxRWJx5ovkfy0BMiVt1LkNMhqzUhyw9aJaeRylgHdj6E09b3ILKBeUfo+xX6IZHbwUrT1M3SsosS4fI14R23sB6kDVEv925PzdRP0mCd6ZOMBw0XB8GiGn0r/gR38umJKhI24JnZgDg1afG5
X-IPAS-Result: A2EVAACV74Zf/zGZrQpgGwEBAQEBAQEBBQEBARIBAQEDAwEBAUCBPQQBAQELAYNFgQgKlUyDepYvgX0EBwEBAQEBAQEBAQQEAS8EAQGESgKCBCY2Bw4CAwEBCwEBAQUBAQEBAQYDAQEBAoZRgjcpAYNqAQEBAQIBeQULAgEIGC4CMCUCBA4FDoMYAYJcEahQdIE0ijkQgTgBgVKLfoFCPoERJxyCTT6CXASBXINLgi0Ekw4BpFsDB4JqhEyCX5NFH6FCr3KDYAIEAgQFAhWBWwSCB3AVZQGCPj4SFwINjioYFI4QdAI2AgYKAQEDCY03gREBAQ
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.1979.3; Wed, 14 Oct 2020 08:35:01 -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.1979.003; Wed, 14 Oct 2020 08:35:01 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
CC: "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>, The IESG <iesg@ietf.org>
Thread-Topic: [EXTERNAL] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Thread-Index: AQHWoLA7Va9FrFzfH0+zqCA6ewMOJqmXTooA
Date: Wed, 14 Oct 2020 12:35:01 +0000
Message-ID: <1C5BF513-7FDD-404E-AC0E-09C0379864E7@verisign.com>
References: <160215590178.19643.8185294724542473578@ietfa.amsl.com> <514C5EA8-2814-42AA-9787-455445BA828D@verisign.com> <MN2PR11MB43665A8B2DE4ECFF99CEAB7EB5070@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB43665A8B2DE4ECFF99CEAB7EB5070@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=_3986BC12-4C73-4498-94F0-A0204F778086"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QckVKyz0hJM0Y3090hHebkuvfJ8>
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: Wed, 14 Oct 2020 12:35:08 -0000


> 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