Re: [secdir] SECDIR review of draft-ietf-dnsop-dns-zone-digest-11

"Wessels, Duane" <dwessels@verisign.com> Mon, 28 September 2020 22:54 UTC

Return-Path: <dwessels@verisign.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731D83A147A; Mon, 28 Sep 2020 15:54:15 -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 re81Ljq9h1C3; Mon, 28 Sep 2020 15:54:13 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.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 242B63A149D; Mon, 28 Sep 2020 15:54:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=10221; q=dns/txt; s=VRSN; t=1601333654; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=9WrD1Snzx4fcjhLgKByqtkpaHUvqvQz8+Jy5OxV5E7Q=; b=VZeOnUPZJkyGazsucpY3/aEh1+3CcRkLDsORxR9Po8OZ/m9ACEJ08Gn/ Ot0/8vrU6/F4AZUfUib7alqtSsWY8EyXOPlrvZ/kpmEA5freG4CGHTszg s7nQJP6/z4nhE75DnejBwcTUSGf62pKjM/ENus3vUFYsHCQzwkqddPF2K f1JnpCuNpbD7pS0RTVdU5hSo9jLJ5jiGClKwsNsGzyD2l81C2HFurzHLp j+rtX8z29OTGxp1kIbCD6AZV/iFf2s9Bde+qaFCbo799GJLnMJSobtBMm Z1taYD23TJGpXrtRP3ECRPI95MwddRLwSQBLVvRqh+qI1pKK0zke9pWH5 w==;
IronPort-SDR: YzfauKbyTdMeLjVST9ln1ailw0dYaLSCbl2tJwW1tKnN4N9eTQDVu4HGpZnL2Xv+pbJYFC+p2L 0a2OUO5g4IsMpRn7BKDMi2zpIaR41FGLsCb1D3lSGhjeodtcaYI4Mp7CGceIQWYdc1v/cGegv1 wtUIu1tV1QzP0kyE3GUw2DX15UyGYUzk5G3iQUgjFUN0xaJ4audfFYBgFn6uWITWQHjl38Z7X7 iouFL5jqLrpgNn5C1SL8TDDuB+6vDkDiWqEDkPeZwOvs4GWqcTcRg/WMUj9fnCeYx4mQmcGku4 QmE=
X-IronPort-AV: E=Sophos; i="5.77,315,1596513600"; d="p7s'?scan'208"; a="3069623"
IronPort-PHdr: 9a23:njCZRhLuLAJxsz01ntmcpTZWNBhigK39O0sv0rFitYgXK/3/rarrMEGX3/hxlliBBdydt6sbzbCJ+Pm7EUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCe/bL9oMhm7rwrdutQYjIB/Nqs/1xzFr2dSde9L321oP1WTnxj95se04pFu9jlbtuwi+cBdT6j0Zrw0QrNEAjsoNWA1/9DrugLYTQST/HscU34ZnQRODgPY8Rz1RJbxsi/9tupgxCmXOND9QL4oVTi+6apgVRnlgzoFOTEk6mHaksx+grxGrhK9qRJxwIDUb4OSOvp/YqzScsgXRWVdUsZUTSFBAp+wY5UJAuEcPehYtY79p14WoBewBQajGvjvyiRWiX/yxq02y/kqHw/b3AM6GdIBrnrYp8jyOagPX+G60rLIzS7dYPNSwjfw85bIfQ47ofGNRrJwcMXRyU81GwzZiVWQrJXoMjWI3esCr2aV9fBvVf6zi2E5sQFxpCCiy8YyhoTUmo4YyVDK+Tt4zYsxKtO1RlJ3bN2qHpZTtyyXNIV4Tt8sTmx1pCo3zr8LtYKmcCUU1JkqxR/SZ+Gaf4WO/xntWuGRITJii3JkfrKynwi98Ee6xe35Tsm01EhFojBZndnLs3AA0QHY5MufSvZl40utxSyD2x3R5+xKO0w4iKrWJpA7zrM/kpcfqVnPEjPslEnrjqKaal8o9vWn5unkeLnqu5yROolpgQ/kKKsugNawAeEgPwgLWGiU5Pqz2aX4/U38XLVKlvo2krTFsJzCJcQUuKq5AwhN34s+9xixFyqq39QAk3cILV1JZAyLg5L3O17SJ/D4F++/j062nzh23fzGIKfhAo7LLnTZjLjherN951ZdyAo1099f+4pZBqwdLP7pR0P8ttLVAgUkPwG0zevrEtpw24cGVWKKGKCZMafSsVGS5uIoJumBfJIauTjjJPg+/P7hk3s5mUQGcKm3w5QXcnG4Hu9nI0WWZ3rgmMsOEWAPvgYmVuzllEWCUSJPZ3a1R68z+z82B5yoAIjdSI2gm7OB3CKhEZ1XYmBKEEyDEXDtd4+cQfcDdDqSItN9kjwDTbWuVpUh2gugtA/m0rZnL/Tb+jEWtZ76ydd14fbTlRYq9TBtEsud1XqNQ3h1n2MPQT85wrlzrlF8yleMz6d4mOBYGcZJ6PNNVgc3Lp/cwPJmC9D8QA7Bec2JSFm+SNW8HT4xVs4xw8MJY0tlGtWtkAvD3yWxDr8UibOLGJI0/rjb33jrKMZ302zG27U5j1k6XstPMnWrhrVh+AfPGoHJkl+Zmr2rdasCwC7N+n2PzW2UvEFXA0ZMVvDpWnYWYkeegN3i+kfLTLLmXbh8P1BMkuaNL6JLbpviilAQF9n5P9GLKV28gHy9AQ3Mjp+RZYznMS1J0DrQE1MJlxs743ucNBM/CSHnqGXbWm89XWnzal/hpLEt4EiwSVU5mlmH
X-IPAS-Result: A2HuAAAPaHJf/zGZrQpgGwEBAQEBAQEBBQEBARIBAQEDAwEBAUCBT4MaLIEICpV6g3qGFJITBAcBAQEBAQEBAQEEBAEbFAQBAQKESQKCMyY4EwIDAQELAQEBBQEBAQEBBgMBAQEChkUMgjcie4EDAQEBAQEBAQEBAQEBAQEBAQEBARYCgRQ1AQEBAQIBeQULAgEIDgouAh8RJQIEDgUOgxgBgksDDhG1ZXSBNIgMDYIUEIE4gVOLdoFCPoERJxyCTT6CGoIiP4MMgi0Em3SKP5A9UQMHgmeESIJfgVSGVYUUaoUMH4NFcJxenBOESY5cg10CBAIEBQIVgWuBe3AVZQGCPgk1EhcCDY4oAgEXg06KVnQ3AgYKAQEDCY1dMl8BAQ
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; Mon, 28 Sep 2020 18:54:11 -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; Mon, 28 Sep 2020 18:54:11 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Donald Eastlake <d3e3e3@gmail.com>
CC: "draft-ietf-dnsop-dns-zone-digest.all@ietf.org" <draft-ietf-dnsop-dns-zone-digest.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, secdir <secdir@ietf.org>
Thread-Topic: [EXTERNAL] SECDIR review of draft-ietf-dnsop-dns-zone-digest-11
Thread-Index: AQHWlUI6Y640j+h6gE6AOdpuc1oe76l+7RaA
Date: Mon, 28 Sep 2020 22:54:10 +0000
Message-ID: <3D8D339D-C83A-45E9-9E0B-027C8F03B136@verisign.com>
References: <CAF4+nEGq3Ez+qMVf1JKxLqBNxb7OA-7Y=-OV4OSHNkVYzA+qoA@mail.gmail.com>
In-Reply-To: <CAF4+nEGq3Ez+qMVf1JKxLqBNxb7OA-7Y=-OV4OSHNkVYzA+qoA@mail.gmail.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=_4E2106C2-6A90-44D0-91FD-B50A9A926E9D"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Cb1zm9RNsm4NHKF_ypSTL4GV5ao>
Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-dns-zone-digest-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2020 22:54:21 -0000


> On Sep 27, 2020, at 7:50 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> The summary of the review is Ready with Nits.
> 
> Overall, I am pretty happy with the state of the draft. Essentially
> all of the comments from my review of -09 have been resolved and I
> don't see any problem with other changes that have been made. However,
> on reviewing -11, I did come up with a few things as listed below.
> 
> Section 2, last sentence right before the Section 2.1 header, should
> "recommended" be all capital?

That change is fine with me.


> 
> Something I didn't notice in my first review:
> Section 2.2.1, ZONEMD already covers the SOA that is in the zone and
> so includes the zone serial in its Digest. Thus it seems a little odd
> to say that the field is needed to make the DNS response meaningful.
> I'm not suggesting removing the field or anything... Perhaps some
> wording change like the following:
> OLD
>   It is included here in order to make DNS response messages of type
>   ZONEMD meaningful.  Without the serial number, a stand-alone ZONEMD
>   digest has no association to any particular instance of a zone.
> NEW
>   It is included here to clearly bind the ZONEMD RR to a particular
>   version of the zone's content. Without the serial number, a
>   stand-alone ZONEMD digest has no obvious association to any
>   particular instance of a zone.

I think that is an improvement.


> 
> Section 3.1, last sentence just before the Section 3.2 header: This
> says ZONEMD RRs are excluded from digest calculation but in Section
> 2.1 it says that non-apex ZONEMD RRs are treated are ordinary RRs and
> included. I think that 2.1 is correct and suggest inserting the word
> "apex" so the last sentence of Section 3.1 starts with "Since apex
> ZONEMD RRs are excluded ..." Although less important, "apex" probably
> should also be inserted before "ZONEMD" in the fourth and sixth bullet
> points of Section 3.3.1.1.

I don't mind inserting "apex" where you suggest.  I felt we were covered
by the earlier statement that ZONEMD means apex ZONEMD unless stated
otherwise, but its good to be explicit in those places.



> 
> Section 5.3, the last sentence, after the table, is no longer needed,
> since that information is given above the table, so it should be
> deleted.

Yes.

> Section 6.2: Need to expand KSK on first use or alternatively, since it
> is the only use, just not use the acronym at all and spell it out in
> full.

Done.


> 
> Section 6.3: Size estimate for ZONEMD RR seems a bit low, perhaps
> based on algorithms in earlier versions of the draft with shorter
> digests. I would say 55 to 85 octets would be a better current
> estimate.

Yes indeed.  I changed it to "65 to 95" now since the smallest SHA384 SIMPLE
RR is 65 bytes and a SHA512 SIMPLE RR for "example.com" is 93 bytes.


> 
> Section 6.4: In the second paragraph, I think you mean "private use
> hash algorithm code points", not "private use hash algorithms".

Yes, thats better.

> 
> That's it.
> 
> Thanks,
> Donald

Thank you again.

DW